Helpful ReplyLockedBuilding USB stack projects with XC8 compiler

Page: 123 > Showing page 1 of 3
Author
PStechPaul
Super Member
  • Total Posts : 2093
  • Reward points : 0
  • Joined: 2006/06/27 16:11:32
  • Location: Cockeysville, MD, USA
  • Status: offline
2012/10/04 04:13:24 (permalink)
0

Building USB stack projects with XC8 compiler

I have finally had some success with building my USB project as well as the USB DEVICE - CDC - Serial Emulator project for the PICDEM FSUSB demo board. I've been able to get it to compile and link, with some conditionals to adjust for differences in the compilers, and I was able to load the software on my target platform, but it does not properly enumerate. The same code, used with MPLAB 8.76 and the C18 compiler, works OK. And it also works in MPLAB X 1.41 if I select the C18 toolset. So there is something quite different with the XC8 compiler.
 
One major difference I see is the location of the descriptor tables. C18 puts them at 1400h while XC8 puts them at 0400h. And I know that the C18 compiler uses the #pragma CODE ADDR to locate sections of code, while the XC8 compiler ignores them. Maybe there is an alternative method of locating code blocks in XC8. I can't do any more at this time, but I could supply the modified files that enabled the project to compile. There were quite a few errors of inconsistent declarations. Perhaps XC8 is a "better" compiler because it adheres more strictly to code standards, but unfortunately at this point I can't use it, at least for my USB projects.
 
Will there be a USB stack that is compatible with XC8?

[edit] I think I found the problem. The BDT (buffer descriptor tables) must be aligned on a 512 byte block, which is done in C18 by using the following:
#define BDT_BASE_ADDR_TAG   __attribute__ ((aligned (512))) 

but in XC8 it is done differently, and is not yet implemented:
 For 16- and 32-bit compilers, change any occurrence of the aligned attribute, as in the following example: 
char __attribute__((aligned(4)))mode; to __align, i.e., __align(4) char mode;
Caveats
This feature is not yet implemented on XC8.
So I thought I could just use absolute addressing, which is also done differently:
 In XC8, change absolute object definitions such as the following example: 
int scanMode @ 0x200; to:
int scanMode __at(0x200);
But I tried that and it gave several errors.
 #ifndef __XC8 
volatile BDT_ENTRY BDT[BDT_NUM_ENTRIES] BDT_BASE_ADDR_TAG;
#else
volatile BDT_ENTRY BDT[BDT_NUM_ENTRIES] __at(0x1400);
#endif
../../../Microchip Solutions v2012-08-22/Microchip/USB/usb_device.c:323: error: "," expected
../../../Microchip Solutions v2012-08-22/Microchip/USB/usb_device.c:323: error: ")" expected
../../../Microchip Solutions v2012-08-22/Microchip/USB/usb_device.c:323: error: illegal function qualifier(s)
So it seems that XC8 cannot be used for USB projects, unless there is some other trick to achieve alignment or absolute addressing. pink
 
post edited by PStechPaul - 2012/10/04 05:26:49

 
#1
Peter Camilleri
Super Member
  • Total Posts : 429
  • Reward points : 0
  • Joined: 2011/10/05 12:19:57
  • Location: Whitby, Ontario
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2012/10/04 06:10:00 (permalink)
0
The user guide section 5.5.4.1 suggests:
 
volatile BDT_ENTRY BDT[BDT_NUM_ENTRIES] @ 0x1400; 

Best regards;

Peter Camilleri
teuthida-technologies.com/
#2
PStechPaul
Super Member
  • Total Posts : 2093
  • Reward points : 0
  • Joined: 2006/06/27 16:11:32
  • Location: Cockeysville, MD, USA
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2012/10/04 13:16:18 (permalink)
+1 (1)
I tried that, and it compiles, but the BDT is still located at 0x0800. When I used it to try to set absolute address for the BDT where it is defined, it seemed to write "0x1400" at address location 0x800. I think the USB protocol is very strict about where the BDT is located, and will not enumerate if improperly placed. I don't understand all that much of the USB stack and I can't dig too deeply into it to make major changes that are probably needed to work with XC8. I'm attaching the files I modified and used for the semi-successful build and a map file for the build using C18, which works.
 
[edit]
A little more progress and understanding...
The BDT is actually located in RAM and its address is specified inusb_hal_pic18.h as
#if defined(__18CXX) 
    #if defined(__18F14K50) || defined(__18F13K50) || defined(__18LF14K50) || defined(__18LF13K50)
        #define USB_BDT_ADDRESS 0x200     //See Linker Script, BDT in bank 2 on these devices - usb2:0x200-0x2FF(256-byte)
    #elif defined(__18F47J53) || defined(__18F46J53) || defined(__18F27J53) || defined(__18F26J53) || defined(__18LF47J53) || defined(__18LF46J53) || defined(__18LF27J53) || defined(__18LF26J53)
        #define USB_BDT_ADDRESS 0xD00  //BDT in Bank 13 on these devices
    #elif defined(__18F97J94) || defined(__18F87J94) || defined(__18F67J94) || defined(__18F96J94) || defined(__18F86J94) || defined(__18F66J94) || defined(__18F96J99) || defined(__18F95J94) || defined(__18F86J99) || defined(__18F85J94) || defined(__18F66J99) || defined(__18F65J94)
        #define USB_BDT_ADDRESS 0x100  //BDT in Bank 1 on these devices
    #else
        #define USB_BDT_ADDRESS 0x400     //All other PIC18 devices place the BDT in usb4:0x400-0x4FF(256-byte)
    #endif
#endif

so I used the following in usb_device.c:
 
/** USB FIXED LOCATION VARIABLES ***********************************/
#if defined(__18CXX)
    #pragma udata USB_BDT=USB_BDT_ADDRESS
#endif
#ifndef __XC8
volatile BDT_ENTRY BDT[BDT_NUM_ENTRIES] BDT_BASE_ADDR_TAG;
#else
volatile BDT_ENTRY BDT[BDT_NUM_ENTRIES] @USB_BDT_ADDRESS;
#endif

Now I have seen that the BDT[] is located at 0x400 and cdc_data_tx is located in USB dual port memory at 0x500. USB RAM is actually from 0x400 to ox7ff.
The USB_SD_Ptr is located at 0x800 in program memory and configDescriptor1 starts at 0x806 as expected. But still the device will not enumerate.
 
I have updated the files in he attached zipfile:
 
[edit] 2012-10-05 I just submitted a support ticket for this issue...
post edited by PStechPaul - 2012/10/04 23:10:34

 
#3
mswh
New Member
  • Total Posts : 10
  • Reward points : 0
  • Joined: 2012/10/05 13:26:18
  • Location: Russia, Moscow
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2012/10/05 13:39:47 (permalink)
0
Hi. I'm tring to do the same thing. I want this USB stack to work with XC8. As I can understand from your post - now it is impossible. Now (00:36 06.10.2012) I've two ways: use C18 or try to find a way to run it undex XC8...
Have you ever asked Microchip about this problem?
 
#4
Peter Camilleri
Super Member
  • Total Posts : 429
  • Reward points : 0
  • Joined: 2011/10/05 12:19:57
  • Location: Whitby, Ontario
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2012/10/05 13:45:47 (permalink)
0
Clearly we're into the "raise a ticket" territory. The @ should have worked!
This now smells like a bug that needs to be squashed!

Best regards;

Peter Camilleri
teuthida-technologies.com/
#5
PStechPaul
Super Member
  • Total Posts : 2093
  • Reward points : 0
  • Joined: 2006/06/27 16:11:32
  • Location: Cockeysville, MD, USA
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2012/10/05 15:06:31 (permalink)
0
I submitted a ticket and the response was that we will have to wait until they release a version of the USB stack that is compatible with XC8, and particularly the PIC18F series processors. I'm not holding my breath! I think I'm pretty close since it does compile and run, although not well enough to function as a USB device. This discussion probably belongs in the USB sub-forum. The compiler is probably OK, and there may be some non-standard tweaks that were used for C18. It may have something to do with pointers and memory addressing. One clue is the difference of location for the descriptors. Using C18 they are shown in the MAP file:

               device_dsc   0x00148c    program     extern C:\PICcode\ORTM4H-USB\usb_descriptors_ORTM4H.c
        configDescriptor1   0x00149e    program     extern C:\PICcode\ORTM4H-USB\usb_descriptors_ORTM4H.c
                    sd000   0x0014e1    program     extern C:\PICcode\ORTM4H-USB\usb_descriptors_ORTM4H.c
                    sd001   0x0014e5    program     extern C:\PICcode\ORTM4H-USB\usb_descriptors_ORTM4H.c
                    sd002   0x001519    program     extern C:\PICcode\ORTM4H-USB\usb_descriptors_ORTM4H.c
                    sd003   0x00154d    program     extern C:\PICcode\ORTM4H-USB\usb_descriptors_ORTM4H.c
               USB_CD_Ptr   0x001563    program     extern C:\PICcode\ORTM4H-USB\usb_descriptors_ORTM4H.c
               USB_SD_Ptr   0x001567    program     extern C:\PICcode\ORTM4H-USB\usb_descriptors_ORTM4H.c

But the MAP file for XC8 is a much different (worse?) format, and the closest thing I could find was:
_configDescriptor1                        smallconst   000806
_device_dsc                               smallconst   0008C7
_sd000                                    smallconst   0008D9
_sd001                                    smallconst   000849
_sd002                                    smallconst   00087D
_sd003                                    smallconst   0008B1

I don't think a ROM memory address should be a "smallconst", and since this location is addressed by means of a BYTE* it might not be working properly. Here is a segment map that may help:

SEGMENTS        Name                           Load    Length   Top    Selector   Space  Class
                reset_vec                      000000  000004  000004         0       0  CODE   
                bssCOMRAM                      000001  00005D  00005E         1       1  COMRAM 
                intcode                        000008  000004  00000C         4       0  CODE   
                intcodelo                      000018  00000E  000026         C       0  CODE   
                bssBANK0                       000060  00006E  0000CE        60       1  BANK0  
                bssBANK1                       000100  000040  000140       100       1  BANK1  
                smallconst                     000800  0000DE  0008DE       400       0  SMALLCON
                text18                         0008DE  001470  001D4E       46F       0  CODE   
                idloc                          200000  000008  200008    200000       0  IDLOC  
                config                         300000  00000E  30000E    300000       0  CONFIG 


 
#6
JTomas
New Member
  • Total Posts : 1
  • Reward points : 0
  • Joined: 2012/10/10 10:25:31
  • Location: 0
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2012/10/10 10:38:38 (permalink)
0
remapping all variable in usb_device.c can obtain that usb work ok with XC8 compiler:
I check with pic18f14k50 and work fine.
These are the changes:
 
USB_VOLATILE USB_DEVICE_STATE USBDeviceState@0x230;
USB_VOLATILE BYTE USBActiveConfiguration@0x231;
USB_VOLATILE BYTE USBAlternateInterface[USB_MAX_NUM_INT]@0x232;
volatile BDT_ENTRY *pBDTEntryEP0OutCurrent@0x233;
volatile BDT_ENTRY *pBDTEntryEP0OutNext@0x235;
volatile BDT_ENTRY *pBDTEntryOut[USB_MAX_EP_NUMBER+1]@0x237;
volatile BDT_ENTRY *pBDTEntryIn[USB_MAX_EP_NUMBER+1]@0x23B;
USB_VOLATILE BYTE shortPacketStatus@0x23F;
USB_VOLATILE BYTE controlTransferState@0x240;
USB_VOLATILE IN_PIPE inPipes[1]@0x241;
USB_VOLATILE OUT_PIPE outPipes[1]@0x246;
USB_VOLATILE BYTE *pDst@0x24D;
USB_VOLATILE BOOL RemoteWakeup@0x24F;
USB_VOLATILE BOOL USBBusIsSuspended@0x250;
USB_VOLATILE USTAT_FIELDS USTATcopy@0x251;
USB_VOLATILE BYTE endpoint_number@0x252;
USB_VOLATILE BOOL BothEP0OutUOWNsSet@0x253;
USB_VOLATILE EP_STATUS ep_data_in[USB_MAX_EP_NUMBER+1]@0x254;
USB_VOLATILE EP_STATUS ep_data_out[USB_MAX_EP_NUMBER+1]@0x256;
USB_VOLATILE BYTE USBStatusStageTimeoutCounter@0x258;
volatile BOOL USBDeferStatusStagePacket@0x259;
volatile BOOL USBStatusStageEnabledFlag1@0x25A;
volatile BOOL USBStatusStageEnabledFlag2@0x25B;
volatile BOOL USBDeferINDataStagePackets@0x25C;
volatile BOOL USBDeferOUTDataStagePackets@0x25D;
 
volatile BDT_ENTRY BDT[BDT_NUM_ENTRIES]@0x200; //BDT_BASE_ADDR_TAG;

volatile CTRL_TRF_SETUP SetupPkt@0x220; //CTRL_TRF_SETUP_ADDR_TAG;
volatile BYTE CtrlTrfData[USB_EP0_BUFF_SIZE]@0x228;
 
void USBDeviceTasks(void)@0x2B2
 
Possibly of other way would be more easy. How does it?
#7
PStechPaul
Super Member
  • Total Posts : 2093
  • Reward points : 0
  • Joined: 2006/06/27 16:11:32
  • Location: Cockeysville, MD, USA
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2012/11/03 02:14:44 (permalink)
0
I have just returned to this project and I tried the absolute locations as you suggested (except for the PIC18F4455 they start in location 0x400). But I found that anything with the qualifier "@" gets located in program ROM space rather than RAM. And the absolute location method shown in the documentation does not work at all. Here is what it says:
 
In XC8, change absolute object definitions such as the following example:
int scanMode @ 0x200;
to:
int scanMode __at(0x200);
But neither one works properly. Maybe it has to do with the PIC18 processor. This has been very frustrating.

 
#8
obama
New Member
  • Total Posts : 21
  • Reward points : 0
  • Joined: 2009/07/25 05:15:53
  • Location: 0
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2012/12/02 09:20:41 (permalink)
0
PStechPaul [edit] 2012-10-05 I just submitted a support ticket for this issue...
Any news for this support ticket? With this patch, can I use XC8 for all PIC with usb controller?
Thank you
 
#9
PStechPaul
Super Member
  • Total Posts : 2093
  • Reward points : 0
  • Joined: 2006/06/27 16:11:32
  • Location: Cockeysville, MD, USA
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2012/12/02 15:59:22 (permalink)
0
The ticket was closed. They said that we must wait for a new release of the stack. I have found other issues with the XC8 compiler as well. There has been an update but I don't have time to do beta testing. The C18 compiler works well enough to get the job done for now. Smile

 
#10
ok_vicinius
New Member
  • Total Posts : 10
  • Reward points : 0
  • Joined: 2012/04/09 11:12:13
  • Location: 0
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2013/04/11 23:25:04 (permalink)
+1 (1)
Guys I found a solution to XC8-HID! (that works for me and i hope that it helps everybody)
 
i'm using PIC18F2550, I first look at the possible lastest file that works with usb framework, than i found this example in microchip solutions (2013-02-15)
MicrochipSolutions/USB/Device - HID - Custom Demos/Firmware/..
 
I converted the "USB Device - HID - Simple Custom Demo - XC32 - PIC32MX795F512L PIM" on MPLABX
 
I get every header and source that correpond of usb framework and introduce it in my project and do a little of changes, (most hardware I/O, like LED,POT BLA BLA BLA) just to compile in XC8 associated with my project.
 
ok, it compile but not get attached, fails when transmit the descriptor, so i look at the net and found this forum, and reading I try just one thing after.
 
inside of "usb_hal_pic18.h" i just modify the address of
#define BDT_BASE_ADDR_TAG   __attribute__ ((aligned (512)))@USB_BDT_ADDRESS
 
forcing the start address to be at pre-determined #define that holds USB_BDT_ADDRESS that is especific to a class of microcontrollers.
 
for me, it's 0x400 (PIC18F2550).... so
 
I compiled it, and TÁDÁ, works everything from now.
 
anyone? i'm waiting for results!
Cya.
 

#11
PStechPaul
Super Member
  • Total Posts : 2093
  • Reward points : 0
  • Joined: 2006/06/27 16:11:32
  • Location: Cockeysville, MD, USA
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2013/04/11 23:44:52 (permalink)
+1 (1)
It may be a while before I can test this, but thanks for coming up with a possible solution. I had problems with the "aligned" directive, and the absolute location alternative located what was supposed to be in RAM, into program ROM (or flash). I'll have to download the latest framework and try it. But the problem seemed to be in the XC8 compiler (or perhaps the linker). What versions of those are you using?

 
#12
newfound
Super Member
  • Total Posts : 1814
  • Reward points : 0
  • Joined: 2003/11/07 12:35:49
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2013/04/12 00:49:48 (permalink)
+2 (2)
A working HID stack for XC8 was posted on this forum about a month or so ago and there have been other reports of working USB stacks for the PIC18 and XC8 going back to Oct 2012. http://www.microchip.com/forums/fb.ashx?m=680523
 
 
It seems that XC8 PIC18 compatibility has been improved from the first release of XC8, just like microchip said it would.
 
 
post edited by newfound - 2013/04/12 00:57:37
#13
ok_vicinius
New Member
  • Total Posts : 10
  • Reward points : 0
  • Joined: 2012/04/09 11:12:13
  • Location: 0
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2013/04/13 10:13:12 (permalink)
0
PStechPaul

It may be a while before I can test this, but thanks for coming up with a possible solution. I had problems with the "aligned" directive, and the absolute location alternative located what was supposed to be in RAM, into program ROM (or flash). I'll have to download the latest framework and try it. But the problem seemed to be in the XC8 compiler (or perhaps the linker). What versions of those are you using?

 
I'm using:
XC8 v1.12
XC32 1.20
MPLAB v1.70
microchip_solutions_v2013-02-15
#14
PStechPaul
Super Member
  • Total Posts : 2093
  • Reward points : 0
  • Joined: 2006/06/27 16:11:32
  • Location: Cockeysville, MD, USA
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2013/04/13 21:42:18 (permalink)
-1 (1)
Well, I just upgraded to the new XC8, MPLABX, and 2-2013 stack, but when I try to compile my project I get:
 
 
../../../Microchip_Solutions_v2013-02-15/Microchip/USB/usb_device.c:279: warning: unknown pragma "udata"
../../../Microchip_Solutions_v2013-02-15/Microchip/USB/usb_device.c:323: warning: unknown pragma "udata"
../../../Microchip_Solutions_v2013-02-15/Microchip/USB/usb_device.c:370: warning: unknown pragma "code"
"C:\Program Files (x86)\Microchip\xc8\v1.12\bin\xc8.exe" --pass1  --chip=18F2450 -Q -G --asmlist  --double=24 --float=24 --emi=wordwrite --opt=default,+asm,-asmfile,+speed,-space,-debug,9 --addrqual=ignore --mode=free -P -N255 -I"C:/PICcode/ORTM4H-USB_XC8" -I"C:/Microchip_Solutions_v2013-02-15" -I"C:/Microchip_Solutions_v2013-02-15/Microchip/Include" -I"C:/Microchip_Solutions_v2013-02-15/Microchip/USB" -I"C:/Microchip_Solutions_v2013-02-15/Microchip/Include/USB" --warn=0 --summary=default,-psect,-class,+mem,-hex,-file --output=default,-inhx032 --runtime=default,+clear,+init,-keep,-no_startup,-download,+config,+clib,+plib "--errformat=%%f:%%l: error: %%s" "--warnformat=%%f:%%l: warning: %%s" "--msgformat=%%f:%%l: advisory: %%s"  -obuild/default/production/_ext/1306123216/usb_function_cdc.p1  "../../../Microchip_Solutions_v2013-02-15/Microchip/USB/CDC Device Driver/usb_function_cdc.c"
../../../Microchip_Solutions_v2013-02-15/Microchip/USB/CDC Device Driver/usb_function_cdc.c:126: warning: unknown pragma "udata"
../../../Microchip_Solutions_v2013-02-15/Microchip/USB/CDC Device Driver/usb_function_cdc.c:200: warning: unknown pragma "udata"
"C:\Program Files (x86)\Microchip\xc8\v1.12\bin\xc8.exe"  --chip=18F2450 -G --asmlist -mdist/default/production/ORTM-4H-R1_USB.X.production.map  --double=24 --float=24 --emi=wordwrite --opt=default,+asm,-asmfile,+speed,-space,-debug,9 --addrqual=ignore --mode=free -P -N255 -I"C:/PICcode/ORTM4H-USB_XC8" -I"C:/Microchip_Solutions_v2013-02-15" -I"C:/Microchip_Solutions_v2013-02-15/Microchip/Include" -I"C:/Microchip_Solutions_v2013-02-15/Microchip/USB" -I"C:/Microchip_Solutions_v2013-02-15/Microchip/Include/USB" --warn=0 --summary=default,-psect,-class,+mem,-hex,-file --output=default,-inhx032 --runtime=default,+clear,+init,-keep,-no_startup,-download,+config,+clib,+plib "--errformat=%%f:%%l: error: %%s" "--warnformat=%%f:%%l: warning: %%s" "--msgformat=%%f:%%l: advisory: %%s"   -odist/default/production/ORTM-4H-R1_USB.X.production.cof  build/default/production/_ext/1472/usb_descriptors_ORTM4H.p1 build/default/production/_ext/1472/main.p1 build/default/production/_ext/16771253/usb_device.p1 build/default/production/_ext/1306123216/usb_function_cdc.p1    
Microchip MPLAB XC8 C Compiler V1.12
Copyright (C) 2012 Microchip Technology Inc.
License type: Node Configuration
C:/Microchip_Solutions_v2013-02-15/Microchip/Include\USB\usb_function_cdc.h:1032: error: could not find space (8 bytes) for variable _cdc_notice
../../../Microchip_Solutions_v2013-02-15/Microchip/USB/CDC Device Driver/usb_function_cdc.c:189: error: could not find space (64 bytes) for variable _cdc_data_tx
../../../Microchip_Solutions_v2013-02-15/Microchip/USB/CDC Device Driver/usb_function_cdc.c:190: error: could not find space (64 bytes) for variable _cdc_data_rx
../../../Microchip_Solutions_v2013-02-15/Microchip/USB/CDC Device Driver/usb_function_cdc.c:193: error: could not find space (8 bytes) for variable _cdc_notice

The problem may be the incompatibility of the #pragma udata directives, which should locate the variables in the proper location in RAM.
I tried the following, which eliminated the errors but still would not link:
 
    __attribute__ ((section ("USB_VARIABLES=0x500")))
        __attribute__((address(0x480)))

So, I used the CDC_Demo project from the new stack, and with its default processor PIC16F1459 it compiled and linked OK. But when I chose the PIC18F4550 which is in my PICDEM FS USB demo board, it gave errors similar to what I saw with my own project. So I looked at the conditionals in the usb_function_cdc.c file, and the definitions for the buffers are much different from those for the PIC18F series:
 
    #elif defined(_16F1459) || defined(_16LF1459) || defined(_16F1454) || defined(_16LF1454) || defined(_16F1455) || defined(_16LF1455)
        #define IN_DATA_BUFFER_ADDRESS 0x2140
        #define OUT_DATA_BUFFER_ADDRESS 0x2190
        #define LINE_CODING_ADDRESS 0x20A0
        #define NOTICE_ADDRESS (LINE_CODING_ADDRESS + LINE_CODING_LENGTH)
        #define IN_DATA_BUFFER_ADDRESS_TAG  @IN_DATA_BUFFER_ADDRESS
        #define OUT_DATA_BUFFER_ADDRESS_TAG @OUT_DATA_BUFFER_ADDRESS
        #define LINE_CODING_ADDRESS_TAG     @LINE_CODING_ADDRESS
        #define NOTICE_ADDRESS_TAG          @NOTICE_ADDRESS

It appears that the problem is caused by incorrect nesting of the compiler conditionals, where the following appears prior to the XC8 switch:
/** V A R I A B L E S ********************************************************/ 
#if defined(__18CXX)

I've had some success by using:
#ifndef __XC8 & defined(__18CXX) 
 
But still no joy. I still get the linker error which can't fit the cdc_rxd and cdc_txd buffers and the cdc_notice. Even when I use absolute addresses in 0x400 and 0x500 space, it is always the same error. When I use the PIC16F1459, it compiles and links OK, but for that PIC the USB variables are located as follows:
        #define IN_DATA_BUFFER_ADDRESS 0x2140 
        #define OUT_DATA_BUFFER_ADDRESS 0x2190
        #define LINE_CODING_ADDRESS 0x20A0

Strangely, the file registers go only to oxFFF, and in the MAP file they are located:
_cdc_data_rx                              (abs)        002A0
_cdc_data_tx                              (abs)        00220
_cdc_mem_type                             bssBANK1     000CE
_cdc_notice                               (abs)        00127

post edited by PStechPaul - 2013/04/13 23:43:33

 
#15
PStechPaul
Super Member
  • Total Posts : 2093
  • Reward points : 0
  • Joined: 2006/06/27 16:11:32
  • Location: Cockeysville, MD, USA
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2013/04/14 16:54:22 (permalink)
0
Well, a bit more (dubious) progress. I was finally able to get the PIC18F4550 version to compile and link under XC8, but it would not enumerate as a USB device. By using the C18 compiler, it worked OK. It seems that the FAR directive for the USB RAM was a problem. Here are the revised portions of the code:
 
//***************** Modified ******************//
//volatile FAR unsigned char cdc_data_tx[CDC_DATA_IN_EP_SIZE] IN_DATA_BUFFER_ADDRESS_TAG;
//volatile FAR unsigned char cdc_data_rx[CDC_DATA_OUT_EP_SIZE] OUT_DATA_BUFFER_ADDRESS_TAG;
volatile unsigned char cdc_data_tx[CDC_DATA_IN_EP_SIZE] IN_DATA_BUFFER_ADDRESS_TAG;
volatile unsigned char cdc_data_rx[CDC_DATA_OUT_EP_SIZE] OUT_DATA_BUFFER_ADDRESS_TAG;
LINE_CODING line_coding LINE_CODING_ADDRESS_TAG;    // Buffer to store line coding information
//volatile FAR CDC_NOTICE cdc_notice NOTICE_ADDRESS_TAG;
volatile CDC_NOTICE cdc_notice NOTICE_ADDRESS_TAG;

I also had to change the header file where it was defined as an extern. These variables were placed in the correct portions of RAM as displayed in the File Registers.
When I compiled using the C18 compiler, I could program the PICdem FS USB board and it enumerated properly. Oddly, however, the configDescriptor1[] seems to appear in program memory location 0x0d30 instead of 0x0808 where it is supposed to be, and where the MAP file shows it.
_configDescriptor1                        smallconst   000808

as well as the LST file:
 
1892  000808                     _configDescriptor1:
  1893  000808  09                  db low(09h)
  1894  000809  02                  db low(02h)
  1895  00080A  43                  db low(043h)
  1896  00080B  00                  db low(0)
  1897  00080C  02                  db low(02h)
  1898  00080D  01                  db low(01h)
  1899  00080E  00                  db low(0)
  1900  00080F  C0                  db low(0C0h)
  1901  000810  32                  db low(032h)

File Registers:
    Address      00   02   04   06   08   0A   0C   0E ASCII 
0D30           0209 0043 0102 C000 0932 0004 0100 0202 ..C..... 2.......
0D40           0001 2405 1000 0401 0224 0502 0624 0100 ...$.... $...$...
0D50           2405 0001 0701 8105 0A03 0100 0409 0001 .$...... ........
0D60           0A02 0000 0700 0205 4002 0000 0507 0282 ........ .@......
0D70           0040 0400 0903 3404 4D03 6900 6300 7200 @......4 .M.i.c.r
0D80           6F00 6300 6800 6900 7000 2000 5400 6500 .o.c.h.i .p. .T.e
0D90           6300 6800 6E00 6F00 6C00 6F00 6700 7900 .c.h.n.o .l.o.g.y
0DA0           2000 4900 6E00 6300 2E00 3400 4303 4400 . .I.n.c ...4.C.D
0DB0           4300 2000 5200 5300 2D00 3200 3300 3200 .C. .R.S .-.2.3.2
0DC0           2000 4500 6D00 7500 6C00 6100 7400 6900 . .E.m.u .l.a.t.i
0DD0           6F00 6E00 2000 4400 6500 6D00 6F00 3000 .o.n. .D .e.m.o.0
0DE0           730D 770D AB0D FF0D 0E1E 6EF6 0E00 6EF7 .s.w.... ...n...n
0DF0           0E00 6EF8 0105 0009 50F5 6FCB 0009 50F5 ...n.... .P.o...P

With the XC8 compiler, these tables appear to be in the correct location, but it doesn't work...
 
    Address      00   02   04   06   08   0A   0C   0E  ASCII
0800           08C5 084B 087F 0808 0209 0043 0102 C000 ..K.... ..C.....
0810           0932 0004 0100 0202 0001 2405 1000 0401 2....... ...$....
0820           0224 0502 0624 0100 2405 0001 0701 8105 $...$... .$......
0830           0A03 0100 0409 0001 0A02 0000 0700 0205 ........ ........
0840           4002 0000 0507 0282 0040 3400 4D03 6900 .@...... @..4.M.i
0850           0A03 A4D8 D001 D001 D038 C056 FFD9 C057 ........ 8.V...W.
0860           5400 6500 6300 6800 6E00 6F00 6C00 6F00 .T.e.c.h .n.o.l.o
0870           6700 7900 2000 4900 6E00 6300 2E00 3400 .g.y. .I .n.c...4
0880           4303 4400 4300 2000 5200 5300 2D00 3200 .C.D.C.  .R.S.-.2
0890           3300 3200 2000 4500 6D00 7500 6C00 6100 .3.2. .E .m.u.l.a
08A0           7400 6900 6F00 6E00 2000 4400 6500 6D00 .t.i.o.n . .D.e.m
08B0           6F00 1200 0001 0202 0000 D808 0A04 0000 .o...... ........
08C0           0101 0002 0401 0903 0004 0427 A4D8 D001 ........ ..'.....
08D0           D001 D019 5025 0B1F 0900 A4D8 D001 D001 ....%P.. ........
08E0           D012 8E30 5026 0A03 A4D8 D001 D001 D005 ..0.&P.. ........
08F0           6E50 0E01 6E14 5050 D006 6E50 0E00 6E14 Pn...nPP ..Pn...n

Maybe I can force them to the same location as for the C18 compiler?? Ah, but I see that part of the descriptor has been corrupted! pink
And now I looked again and it seems to be OK!
 
    Address      00   02   04   06   08   0A   0C   0E     ASCII
0800           08C5 084B 087F 0808 0209 0043 0102 C000 ..K.... ..C.....
0810           0932 0004 0100 0202 0001 2405 1000 0401 2....... ...$....
0820           0224 0502 0624 0100 2405 0001 0701 8105 $...$... .$......
0830           0A03 0100 0409 0001 0A02 0000 0700 0205 ........ ........
0840           4002 0000 0507 0282 0040 3400 4D03 6900 .@...... @..4.M.i
0850           6300 7200 6F00 6300 6800 6900 7000 2000 .c.r.o.c .h.i.p.
0860           5400 6500 6300 6800 6E00 6F00 6C00 6F00 .T.e.c.h .n.o.l.o
0870           6700 7900 2000 4900 6E00 6300 2E00 3400 .g.y. .I .n.c...4
0880           4303 4400 4300 2000 5200 5300 2D00 3200 .C.D.C.  .R.S.-.2
0890           3300 3200 2000 4500 6D00 7500 6C00 6100 .3.2. .E .m.u.l.a
08A0           7400 6900 6F00 6E00 2000 4400 6500 6D00 .t.i.o.n . .D.e.m
08B0           6F00 1200 0001 0202 0000 D808 0A04 0000 .o...... ........
08C0           0101 0002 0401 0903 0004 0427 A4D8 D001 ........ ..'.....
08D0           D001 D019 5025 0B1F 0900 A4D8 D001 D001 ....%P.. ........
08E0           D012 8E30 5026 0A03 A4D8 D001 D001 D005 ..0.&P.. ........

And when I tried to build and program the device, MPLABX went pftt and disappeared so I have to restart it...
OK, restarted and it runs again. So I noticed that, with XC8, the outPipes is at 0x001 and inPipes at 0x038. That doesn't seem right. So I selected C18 again. Well, I have one gripe with that - it loses its include directories so it can't find some files. OK, annoying but easily fixed. Now, using XC8, outPipes is 0x5ac and inPipes is ox5a7. There are a bunch of USB variables that should be located in USB dual-port RAM. Somehow C18 gets it right, while XC8 does not...
In usb_device.c"
 
#ifndef __XC8
    #if defined(__18CXX)
    #pragma udata
    #endif
#endif
USB_VOLATILE USB_DEVICE_STATE USBDeviceState;
USB_VOLATILE BYTE USBActiveConfiguration;
USB_VOLATILE BYTE USBAlternateInterface[USB_MAX_NUM_INT];
volatile BDT_ENTRY *pBDTEntryEP0OutCurrent;
volatile BDT_ENTRY *pBDTEntryEP0OutNext;
volatile BDT_ENTRY *pBDTEntryOut[USB_MAX_EP_NUMBER+1];
volatile BDT_ENTRY *pBDTEntryIn[USB_MAX_EP_NUMBER+1];
USB_VOLATILE BYTE shortPacketStatus;
USB_VOLATILE BYTE controlTransferState;
USB_VOLATILE IN_PIPE inPipes[1];
USB_VOLATILE OUT_PIPE outPipes[1];
USB_VOLATILE BYTE *pDst;
USB_VOLATILE BOOL RemoteWakeup;
USB_VOLATILE BOOL USBBusIsSuspended;
USB_VOLATILE USTAT_FIELDS USTATcopy;
USB_VOLATILE BYTE endpoint_number;
USB_VOLATILE BOOL BothEP0OutUOWNsSet;
USB_VOLATILE EP_STATUS ep_data_in[USB_MAX_EP_NUMBER+1];
USB_VOLATILE EP_STATUS ep_data_out[USB_MAX_EP_NUMBER+1];
USB_VOLATILE BYTE USBStatusStageTimeoutCounter;
volatile BOOL USBDeferStatusStagePacket;
volatile BOOL USBStatusStageEnabledFlag1;
volatile BOOL USBStatusStageEnabledFlag2;
volatile BOOL USBDeferINDataStagePackets;
volatile BOOL USBDeferOUTDataStagePackets;

and USB_VOLATILE is simply:
 
#if defined(USB_POLLING)
    #define USB_VOLATILE
#else
    #define USB_VOLATILE volatile
#endif

In this case USB_POLLING is defined so USB_VOLATILE does not have a specific definition...
Well, I used the advice given by BThomas earlier, and when I set the BDT to the fixed address @BDT_ADDRESS, it just barely finished building and programming when XC8 went pffft again, but miraculously, it finally seems to work! I don't see how anyone could have gotten this to work without at least some of the kludges I made to the USB stack. I think I'll give it a rest now, and then I'll put together a package with the changes I made, and also make another ticket. There are some nice things about the MPLABX IDE and I may try to use it more now (although MPLAB 8.89 is much faster), but I'm not so sure about XC8, although the problem may well be still the USB stack which I think I have fixed, at least for my PIC18F2550... mr green
post edited by PStechPaul - 2013/04/14 19:24:29

 
#16
sylvain
New Member
  • Total Posts : 3
  • Reward points : 0
  • Joined: 2010/10/04 06:18:54
  • Location: 0
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2013/04/17 02:05:16 (permalink)
0
dear all !
i try to understand what you're doing to compile the microchip usb stack but i hav somme problems !
 
So could someone, please, resume and explain what we must change on usb stack  to compile  usb HID or USB CDC with a 18f2550 or 18f4550 ?
 
thank you for all your work !!
#17
PStechPaul
Super Member
  • Total Posts : 2093
  • Reward points : 0
  • Joined: 2006/06/27 16:11:32
  • Location: Cockeysville, MD, USA
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2013/04/17 12:59:29 (permalink)
0
I copied all the files that I changed into a folder and zipped it. These changes were specifically to use the PIC18F2550 which is in my PICdem FS USB development board, and I have only verified that it compiles, links, and loads, and when the device is programmed it enumerates successfully. However, I just now found out that the device cannot start, so there is still a problem. I don't have time now to try anything more, but I expect that it could be tracked down by comparing the LST files to see where the differences may be. If you or anyone else finds a solution, please post it here. Thanks.

 
#18
mad_c
Super Member
  • Total Posts : 1126
  • Reward points : 0
  • Joined: 2010/12/12 17:48:27
  • Location: Brisbane, Australia
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2013/04/17 14:45:43 (permalink)
0
PStechPaul

I have just returned to this project and I tried the absolute locations as you suggested (except for the PIC18F4455 they start in location 0x400). But I found that anything with the qualifier "@" gets located in program ROM space rather than RAM. And the absolute location method shown in the documentation does not work at all. Here is what it says:

In XC8, change absolute object definitions such as the following example:
int scanMode @ 0x200;
to:
int scanMode __at(0x200);
But neither one works properly. Maybe it has to do with the PIC18 processor. This has been very frustrating.

I have not been following this thread, but this comes as quite a surprise. Absolute objects define every SFR, so they are very well tested. I have certainly not heard anything about failures with absolutes variables. Can you post a simple example of what you are seeing, with a description of what you mean by 'works properly'. Please explain how you are confirming the address allocated to the objects etc. If you have the support ticket number, too, I can take a look at that. The small examples you post above should work fine, but maybe there is more to your code than this.
 
Jeff.
#19
PStechPaul
Super Member
  • Total Posts : 2093
  • Reward points : 0
  • Joined: 2006/06/27 16:11:32
  • Location: Cockeysville, MD, USA
  • Status: offline
Re:Building USB stack projects with XC8 compiler 2013/04/17 19:39:17 (permalink)
-1 (1)
The zipfile I attached has everything needed to build the project. I used the CDC Serial Emulator demo for the PIC16F1459 which compiled, linked, and loaded OK. But when I set the processor to the PIC18F4550 which is in the PICdem FS USB board, it had problems that were resolved only by making changes to the stack files. Perhaps I should go back and use the associated project file, but I think I already did that. I'm sure I found some serious errors for the PIC18 series. It probably works for the dsPIC and the PIC16 and PIC14K processors.
 
I just tried to build the CDC Basic Demo. I had to add the paths to some files. Then I got these errors:
(From USB_descriptors.c)
#if defined(__18CXX)
#pragma romdata
#endif
...
#if defined(__18CXX)
    #pragma code
#endif
 
(from main.c)
 #pragma code REMAPPED_RESET_VECTOR = REMAPPED_RESET_VECTOR_ADDRESS
 void _reset (void)
 {
     _asm goto _startup _endasm
 }

Here are the error messages:

"C:\Program Files (x86)\Microchip\xc8\v1.12\bin\xc8.exe" --pass1  --chip=18F4550 -Q -G --asmlist  --double=24 --float=24 --emi=wordwrite --opt=default,+asm,-asmfile,+speed,-space,-debug,9 --addrqual=ignore --mode=free -P -N255 -I"C:/Microchip_Solutions_v2013-02-15/Microchip" -I"C:/Microchip_Solutions_v2013-02-15/Microchip/Include" -I"C:/Microchip_Solutions_v2013-02-15/USB/Device - CDC - Basic Demo/Firmware" --warn=0 --summary=default,-psect,-class,+mem,-hex,-file --output=default,-inhx032 --runtime=default,+clear,+init,-keep,-no_startup,-download,+config,+clib,+plib "--errformat=%%f:%%l: error: %%s" "--warnformat=%%f:%%l: warning: %%s" "--msgformat=%%f:%%l: advisory: %%s"  -obuild/default/production/_ext/1472/usb_descriptors.p1  ../usb_descriptors.c
../usb_descriptors.c:162: warning: unknown pragma "romdata"
../usb_descriptors.c:302: warning: unknown pragma "code"
"C:\Program Files (x86)\Microchip\xc8\v1.12\bin\xc8.exe" --pass1  --chip=18F4550 -Q -G --asmlist  --double=24 --float=24 --emi=wordwrite --opt=default,+asm,-asmfile,+speed,-space,-debug,9 --addrqual=ignore --mode=free -P -N255 -I"C:/Microchip_Solutions_v2013-02-15/Microchip" -I"C:/Microchip_Solutions_v2013-02-15/Microchip/Include" -I"C:/Microchip_Solutions_v2013-02-15/USB/Device - CDC - Basic Demo/Firmware" --warn=0 --summary=default,-psect,-class,+mem,-hex,-file --output=default,-inhx032 --runtime=default,+clear,+init,-keep,-no_startup,-download,+config,+clib,+plib "--errformat=%%f:%%l: error: %%s" "--warnformat=%%f:%%l: warning: %%s" "--msgformat=%%f:%%l: advisory: %%s"  -obuild/default/production/_ext/1472/main.p1  ../main.c
../main.c:319: warning: unknown pragma "udata"
../main.c:370: warning: unknown pragma "code"
../main.c:373: error: expression syntax
../main.c:374: error: ";" expected
../main.c:376: warning: unknown pragma "code"
../main.c:379: error: expression syntax
../main.c:380: error: ";" expected
../main.c:381: warning: unknown pragma "code"
../main.c:384: error: expression syntax
../main.c:385: error: ";" expected
../main.c:405: warning: unknown pragma "code"
../main.c:408: error: expression syntax
../main.c:409: error: ";" expected
../main.c:410: warning: unknown pragma "code"
../main.c:413: error: expression syntax
../main.c:414: error: ";" expected
../main.c:417: warning: unknown pragma "code"
../main.c:421: warning: unknown pragma "interrupt"
../main.c:433: warning: unknown pragma "interruptlow"
../main.c:484: warning: unknown pragma "code"

post edited by PStechPaul - 2013/04/17 20:13:18

 
#20
Page: 123 > Showing page 1 of 3
Jump to:
© 2018 APG vNext Commercial Version 4.5