From: M L <mar...@gm...> - 2011-11-09 09:54:24
|
Hi, I searched sdcc archives about some usable & wroking USB library and I found some posts about gpled USB stack writtten by Alexander Enzmann ( file usb.zip found on nutsvols.com). This library was created using sdcc version 2.5 (according to some comments in the source files) and it contains precompiled hex files, too. I tried to recompile PICHID library example with my sdcc 3.0.2 and pic18f2550. Fisrt it fails with some casting erros with lines: outPtr = &deviceDescriptor; so I changed it to outPtr = (byte *)&deviceDescriptor; then compilation was succesfull. But it won't work. My usb host (Linux) reports errors after pic flashing & boot: usb 1-6: new full speed USB device using ohci_hcd and address 11 usb 1-6: device descriptor read/64, error -62 usb 1-6: device descriptor read/64, error -62 When I flashed old recompiled hex (mentioned above), it works and USB host reports: usb 1-6: new full speed USB device using ohci_hcd and address 15 usb 1-6: configuration #1 chosen from 1 choice HID device claimed by neither input, hiddev nor hidraw and lsusb reports new usb device: Bus 001 Device 015: ID 04d8:4541 Microchip Technology, Inc. I switched on some debug (printed via serial): Enable the module Device powered USB Test Startup Enable the module Device powered BusReset BusReset ProcessControlTransfer USTAT =0 SetupStage ProcessStandardRequest GetDescriptor DEVICE_DESCRIPTOR InDataStage bufferSize=18 ProcessControlTransfer USTAT =0x04 InDataStage bufferSize=0 ProcessControlTransfer USTAT =0 BusReset ProcessControlTransfer USTAT =0 SetupStage ProcessStandardRequest GetDescriptor DEVICE_DESCRIPTOR InDataStage bufferSize=18 ProcessControlTransfer USTAT =0x04 InDataStage bufferSize=0 ProcessControlTransfer USTAT =0 BusReset BusReset ProcessControlTransfer USTAT =0 SetupStage ProcessStandardRequest GetDescriptor DEVICE_DESCRIPTOR InDataStage bufferSize=18 ProcessControlTransfer USTAT =0x04 InDataStage bufferSize=0 ProcessControlTransfer USTAT =0 BusReset ProcessControlTransfer USTAT =0 SetupStage ProcessStandardRequest GetDescriptor DEVICE_DESCRIPTOR InDataStage bufferSize=18 ProcessControlTransfer USTAT =0x04 InDataStage bufferSize=0 ProcessControlTransfer USTAT =0 BusReset BusReset ProcessControlTransfer USTAT =0 SetupStage ProcessStandardRequest SET_ADDRESS: 12 ProcessControlTransfer USTAT =0x04 UADDR = 0x12 ProcessControlTransfer USTAT =0 SetupStage ProcessStandardRequest GetDescriptor DEVICE_DESCRIPTOR InDataStage bufferSize=8 ProcessControlTransfer USTAT =0x04 InDataStage bufferSize=0 ProcessControlTransfer USTAT =0 ProcessControlTransfer USTAT =0 SetupStage ProcessStandardRequest GetDescriptor DEVICE_DESCRIPTOR InDataStage bufferSize=8 ProcessControlTransfer USTAT =0x04 InDataStage bufferSize=0 ProcessControlTransfer USTAT =0 BusReset ProcessControlTransfer USTAT =0 SetupStage ProcessStandardRequest SET_ADDRESS: 13 ProcessControlTransfer USTAT =0x04 UADDR = 0x13 ProcessControlTransfer USTAT =0 SetupStage ProcessStandardRequest GetDescriptor DEVICE_DESCRIPTOR InDataStage bufferSize=8 ProcessControlTransfer USTAT =0x04 InDataStage bufferSize=0 ProcessControlTransfer USTAT =0 ProcessControlTransfer USTAT =0 SetupStage ProcessStandardRequest GetDescriptor DEVICE_DESCRIPTOR InDataStage bufferSize=8 ProcessControlTransfer USTAT =0x04 InDataStage bufferSize=0 ProcessControlTransfer USTAT =0 It looks like pic try to send (many times) dev descriptor w/o success. Maybe someone has any hints why it won't works... or maybe exist somewhere and usable (with sdcc) usb stack for pic18f? I tried other usb libs puf, eva but both are based on the same stack form nutsvols... regards, marico |
From: Kustaa N. <Kus...@pl...> - 2011-11-09 10:08:44
|
On 11/9/11 11:54, "M L" <mar...@gm...> wrote: >outPtr = &deviceDescriptor; >so I changed it to >outPtr = (byte *)&deviceDescriptor; >From the top of my head and not looking at the code, pointers in SDCC/PIC come in three types depending weather they refer to RAM, ROM or are generic. Your cast above may be generating a generic pointer where as most likely the original code intended a data (__data byte*) or code pointer (__code byte*) depending where 'deviceDescriptor' is. The USB hardware in the pic only handless transfer to/from RAM (data), but most likely the actual device descriptor is in ROM (code). So examine the code to see what 'deviceDescriptor' is in your code and cast as appropriate. I may be totally wrong of course. br Kusti |
From: M L <mar...@gm...> - 2011-11-09 11:03:27
|
Hi, Of course I checked it, pointers point to correct tables with correct values. I printed out (via serial) vaules send to host durning InDataStage but I cut it off from the previous post. This is the debug fragment with InDataStage call: [...] GetDescriptor DEVICE_DESCRIPTOR InDataStage bufferSize=18 0 outPtr=12 1 outPtr=1 2 outPtr=0 3 outPtr=2 4 outPtr=0 5 outPtr=0 6 outPtr=0 7 outPtr=20 8 outPtr=d8 9 outPtr=4 10 outPtr=41 11 outPtr=45 12 outPtr=1 13 outPtr=0 14 outPtr=1 15 outPtr=2 16 outPtr=0 17 outPtr=1 ProcessControlTransfer USTAT =0x04 [...] The above outPtr values (12,1,0,2,...) are from dev desc. table: __code byte deviceDescriptor[] = { 0x12, 0x01, // bLength, bDescriptorType 0x00, 0x02, // bcdUSB (low byte), bcdUSB (high byte) 0x00, 0x00, // bDeviceClass, bDeviceSubClass 0x00, E0SZ, // bDeviceProtocl, bMaxPacketSize 0xD8, 0x04, // idVendor (low byte), idVendor (high byte) 0x41, 0x45, // idProduct (low byte), idProduct (high byte) 0x01, 0x00, // bcdDevice (low byte), bcdDevice (high byte) 0x01, 0x02, // iManufacturer, iProduct 0x00, 0x01 // iSerialNumber (none), bNumConfigurations }; so pointers are OK. regards, marico 2011/11/9 Kustaa Nyholm <Kus...@pl...>: > On 11/9/11 11:54, "M L" <mar...@gm...> wrote: >>outPtr = &deviceDescriptor; >>so I changed it to >>outPtr = (byte *)&deviceDescriptor; > > >From the top of my head and not looking at the code, > pointers in SDCC/PIC come in three types depending weather > they refer to RAM, ROM or are generic. > > Your cast above may be generating a generic pointer > where as most likely the original code intended a data > (__data byte*) or code pointer (__code byte*) > depending where 'deviceDescriptor' is. > > The USB hardware in the pic only handless transfer > to/from RAM (data), but most likely the actual device > descriptor is in ROM (code). So examine the code > to see what 'deviceDescriptor' is in your code > and cast as appropriate. > > I may be totally wrong of course. > > br Kusti > > > > > > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Vaclav P. <vac...@se...> - 2011-11-09 11:19:56
|
Hi, some time before I successfully compiled this stack with SDCC 2.9.x (I don't remember yet) for PIC18F2455. Then I ported the stack to USB CDC and bulk transfers. If you still need it, I will try to look into my archives and send it to you. Vaclav |
From: M L <mar...@gm...> - 2011-11-14 12:37:53
|
You were right, Other pointer point to usbram memory: inPtr =(byte *) &controlTransferBuffer; were controlTransferBuffer is: #pragma udata usbram5 controlTransferBuffer volatile byte controlTransferBuffer[E0SZ]; changing code to: inPtr =(__data byte *) &controlTransferBuffer; fixed my problems. For me this is an unusual sdcc behavior, I often use pointers to char arrays, like: char buf[32], *p; p=&buf and "p" points correctly to buf, which is located in ram. So why it won't work with usbram ? regards, 2011/11/9 Kustaa Nyholm <Kus...@pl...>: > On 11/9/11 11:54, "M L" <mar...@gm...> wrote: >>outPtr = &deviceDescriptor; >>so I changed it to >>outPtr = (byte *)&deviceDescriptor; > > >From the top of my head and not looking at the code, > pointers in SDCC/PIC come in three types depending weather > they refer to RAM, ROM or are generic. > > Your cast above may be generating a generic pointer > where as most likely the original code intended a data > (__data byte*) or code pointer (__code byte*) > depending where 'deviceDescriptor' is. > > The USB hardware in the pic only handless transfer > to/from RAM (data), but most likely the actual device > descriptor is in ROM (code). So examine the code > to see what 'deviceDescriptor' is in your code > and cast as appropriate. > > I may be totally wrong of course. > > br Kusti > > > > > > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |