lwIP_CDC USB with ARM7_AT91SAM7S64_IAR

I am trying to integrate the CDC USB sample code and driver provided with the lwIP_Demo_Rowley_ARM7 sample program into the ARM7_AT91SAM7S64_IAR that I have running on an AT91SAM7S-EK development kit. I replaced the USBSample.c file from the IAR demo with the USB files provided in the Rowley demo. I also changed the USB ISR prototype and function call as follows: was: void vUSB_ISR( void ) __attribute__ ((naked)); void vUSB_ISR( void ) { …. } changed to: __arm void vUSB_ISR( void ); __arm void vUSB_ISR( void ) { …. } I also commented out portENTER_SWITCHING_ISR(); because the ISR is still called from USB_ISR.s79 and changed: portEXIT_SWITCHING_ISR( cTaskWokenByPost ) to portEND_SWITCHING_ISR( cTaskWokenByPost ) Finally, in vInitUSBInterface() I changed: AT91F_AIC_ConfigureIt( AT91C_ID_UDP, usbINTERRUPT_PRIORITY, AT91C_AIC_SRCTYPE_INT_HIGH_LEVEL, ( void (*)( void ) ) vUSB_ISR ); to AT91F_AIC_ConfigureIt( AT91C_BASE_AIC, AT91C_ID_UDP, usbINTERRUPT_PRIORITY, AT91C_AIC_SRCTYPE_INT_HIGH_LEVEL, ( void (*)( void ) ) vUSBISREntry ); I found that the unit did not even register itself properly – the computer recognized that a USB device was plugged in, but did not recognize the device descriptor. After comparing the code from the previously included HID driver, I found that the original ISR code wrote to pxMessage->ucFifoData[] in reverse order, while the new code writes to it in forward order. By changing it back to reverse order and changing the definitions of data indexes for reading the request from the xISRStatus.ucFifoData[] into xUSB_REQUEST back to reverse order, the unit now registers and my computer installs the correct driver when pointed to it. Deregistering and reregistering now seem to work. My problem now is that when I try and access the virtual COM port that was created using Hyperterm, Hyperterm hangs up. It never connects and sits there waiting for something and finally times out. I tried reversing the order of the data back to forward order when copying it to pxControlRx.ucBuffer in prvProcessEndPoint0Interrupt() and tried eliminating optimization, but had no change in symptoms. Using my JTAG debugger, I verified that I am getting calls to prvHandleClassInterfaceRequest() with requests for usbGET_LINE_CODING and usbSET_CONTROL_LINE_STATE. Can someone verify that the USB source for the lwIP_Demo_Rowley_ARM7 sample program actually does work, as I was surprised that the AT91F_AIC_ConfigureIt() function was called with the first argument missing and would not even compile. If someone is familiar with the CDC driver sample program, can you please give me some suggestions on what else I would need to look at or why changing the order of data in ucFifoData and xUSB_REQUEST definitions should fix my registration problem? Finally, if someone is aware of any subtle differences between the IAR compiler and the Rowley compiler that could shed some light on what else I need to be wary of, that would also be helpful. Thanks in advance for any help someone can give. Regards Kris

lwIP_CDC USB with ARM7_AT91SAM7S64_IAR

A brief reply as I’m on a dodgy mobile modem – The Rowley demo definitely does work, but be aware that the CDC driver is not fully USB compliant.  I am told it is fine on Windows but not on Linux. The Rowley code does not use the library directly as there was some problem with the inlining (can’t remember exactly what) so some of the library code was copied into the main code, and the first parameter not used as it was hard coded. Regards.