Hello everyone,
please help me find the solution to this problem:
I'm writing a composite device firmware for an Atmel SAM7S256 mcu. The firmware incorporates a usb keyboard and a HID. Because I have only 4 endpoints to use with this MCU, I am assigning 1 endpoint (EP1) to the keyboard interface, and 2 endpoints (EP2 (in) and EP3 (out)) to the other interface.
The problem is that when I write to EP3, my host program hangs (probably because the firmware hangs too). My firmware is an adaptation of the Atmel provided sample keyboard firmware. The composite device enumerates just fine (keyboard + HID).
What could be wrong?
I don't know enough of the AT91 usb stack to understand IF I have to change anything else in the code to add those 2 endpoints to the second interface. My understand is that this change would be enough:
typedef struct { USBConfigurationDescriptor configuration; // first interface USBInterfaceDescriptor interface0; HIDDescriptor hid0; USBEndpointDescriptor interruptIn0; // second interface USBInterfaceDescriptor interface1; HIDDescriptor hid1; USBEndpointDescriptor interruptIn1; USBEndpointDescriptor interruptOut1; } __attribute__ ((packed)) HIDDKeyboardDriverConfigurationDescriptors;
Here's my understanding of how HID device works: when the device firmware receives a SET_REPORT request on the control EP, it reads the content of the control EP and makes a call to USB_Read() passing the number of the endpoint to read and a call back function. So, I am checking the content of the interface #, and if it is 1, I pass the EP3 to USB_Read(). But this mechanism doesn't seem to be working for me. :(
Please help me out with any hints. Is Tsuneo still in the forum?
Thanks a million. Paulo
Maybe, you are working on the Atmel package/AT91LIB, aren't you?
AT91SAM7S-EK Software Package for IAR 5.2, Keil and GNU or AT91LIB version 1.5 www.atmel.com/.../SAM7S-EK.aspx
To make a composite device of keyboard and vendor-specific HID on this stack, you have to bind two class drivers, \at91sam7s-ek\packages\usb-device-hid-keyboard-project-at91sam7s-ek\at91lib\usb\device\hid-keyboard \at91sam7s-ek\packages\usb-device-hid-transfer-project-at91sam7s-ek\at91lib\usb\device\hid-transfer
As your device is enumerated, you've finished descriptor work.
When the device receives a control transfer, USBDCallbacks_RequestReceived() is called by the stack. Your composite firmware implements this callback as follows, so that the request is passed to the target interface.
enum { HIDDKeyboardDriver_INTERFACENUM, HIDDTransferDriver_INTERFACENUM, COMPOSITEDDriverDescriptors_NUMINTERFACE // number of interfaces }; void USBDCallbacks_RequestReceived(const USBGenericRequest *request) { if ( USBGenericRequest_GetIndex(request) == HIDDKeyboardDriver_INTERFACENUM ) { HIDDKeyboardDriver_RequestHandler(request); } if ( USBGenericRequest_GetIndex(request) == HIDDTransferDriver_INTERFACENUM ) { HIDDTransferDriver_RequestHandler(request); } }
> Here's my understanding of how HID device works: when the device firmware receives a SET_REPORT request on the control EP, it reads the content of the control EP and makes a call to USB_Read() passing the number of the endpoint to read and a call back function.
Your understanding is fine, when your PC application really puts a SET_REPORT request.
> The problem is that when I write to EP3, my host program hangs
Write on EP3 of the host app doesn't cause SET_REPORT request. Your firmware calls USBD_Read() for EP3 at USBDDriverCallbacks_ConfigurationChanged(), as follows.
void USBDDriverCallbacks_ConfigurationChanged(unsigned char cfgnum) { if (cfgnum > 0) { hiddTransferDriver.iLen = 0; USBD_Read(HIDDTransferDriverDescriptors_INTERRUPTOUT, // <--- EP3 hiddTransferDriver.iBuf, HIDDTransferDriver_REPORTSIZE, HIDDTransferDriver_DataReceived, 0); } }
This USBD_Read() arms a buffer (hiddTransferDriver.iBuf) and callback (HIDDTransferDriver_DataReceived) to EP3. When the stack receives an output report (packet) on EP3, this report is kept on this buffer, and registered callback is called.
Tsuneo
Tsuneo,
you made some very good points. Although my device enumerates fine, I see your point about having two RequestHandlers. The way I am responding to the HIDGenericRequest_SETREPORT request for the HID transfer device isn't correct.
I'll make a few changes and will report back here.
I immensely appreciate your help.
Paulo.
View all questions in Keil forum