To the NXP USB experts,
Like many, I'm using the the Keil usbcdc demo. I am using it on an NXP LPC2478 on the Embedded Artists QVGA development board. I do have some questions below, but I also wanted to get my findings up on this board in case they will help others.
The first issue that I had was with GPIO 1.27. Using PINSEL3, I have that GPIO set to be either USB_INT1/LCDVD[13]/LCDVD[21] because I'm using that pin as the Blue[5] LCD data line. Unfortunately, whenever PINSEL3 is setup in that way, if I enable the USB interrupts, I continuously get interrupted and the USB_ISR isn't capable of clearing the interrupt. Because of that, the interrupt just keeps immediately getting called and the program effectively hangs. If I make GPIO 1.27 a regular GPIO then there are no problems with the USB interrupts, but then my Blue[5] data line to the LCD isn't being driven, so that's not really a viable solution. My guess is that since GPIO 1.27 is muxed as USB_INT1 and LCDVD[13]/[21] that the USB_INT1 is for some reason causing the USB interrupt. From what I can tell, that USB_INT1 is supposed to be used for an external USB OTG controller, which I am not using. There is an external OTG controller on the Embedded Artists QVGA board, but I've got the jumpers configured such that it is not being used. Does anyone know how to use that LCDVD[21] line and actually use USB without the USB interrupt firing all the time?
When GPIO 1.27 is set to be a GPIO I could enumerate just fine. I have Total Phase's great Beagle hardware sniffer and I can see that I'm responding to all the requisite enumeration packets and the host is happy because I can see that there is a new comm port in my device manager. Unfortunately, at first I wasn't getting any interrupts when trying to send my device a little message from Docklight, which is a great terminal program. With a little digging into the NXP datasheet, I found the problem....
My second issue was with the NXP's setting of the endpoint realization register, named USBReEp in the datasheet or REALIZE_EP in lpc24xx.h. In order for the SIE to actually communicate with an endpoint, the endpoint must be set in the REALIZE_EP register. By default, the two control endpoints are set and the code also sets those control endpoints in the USB_Configure() function within usbhw.c. The other endpoints get set in the function called USB_ConfigEP(), which is called when usbcore.c gets a SET_CONFIGURATION control packet from the host. Well, not just any SET_CONFIGURATION control packet, but one that has a descriptorType of USB_ENDPOINT_DESCRIPTOR_TYPE. Unfortunately, on my PC running 32-bit Vista, I do not get a SET_CONFIGURATION control packet with the USB_ENDPOINT_DESCRIPTOR_TYPE descriptorType, so the endpoints are not getting set in the REALIZE_EP.
Since I can see that there is no way the endpoints are going to be set in the REALIZE_EP register as written, I modified USB_Configure() to also configure endpoints 1 and 2 since that is what CDC code uses, I now have the usb cdc working just fine. I can send out bytes and receive bytes on endpoint 2, so that looks like that was the only problem I had.
So, the question for this issue is: does anyone know why those endpoints weren't being set in the REALIZE_EP? Do most hosts send out a SET_CONFIGURATION control packet with the USB_ENDPOINT_DESCRIPTOR_TYPE descriptor type for the endpoints that are being used during the enumeration process? If not, then I'm wondering how this code would work in the first place. Since I'm not seeing anyone else complain about this, I'm really confused as to why I'm the only one that is having this issue. Maybe there's something else that I'm missing?
Since I've got the code working now, I'm not too concerned about the endpoints not being realized, but if there's a deeper underlying problem that I'm just covering up, it would be nice to know about that. But, I do need to use GPIO 1.27 as an LCD data line, so if anyone has any idea on how to use it as such without it making my USB interrupt occur, please let me know. Thanks and sorry this was so long winded. Again, hopefully someone will be able to make use of this posting.
Jim