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
All,
I think I found the issue with GPIO 1.27 and the dual purpose USB OTG interrupt and LCD driver pin.
In my application I was enabling USB prior to the LCD initialization. My procedure was to start up the USB, then initialize the LCD pin setups (using PINSEL3 to set GPIO 1.27 to the LCDVD[21] function) and then set up the LCD controller via the LCD specific registers. But, as soon as I set GPIO 1.27 to be LCDVD[21]/USB_INT1 when the USB was enabled, the interrupt for USB_INT1 was triggered and I was never able to get out of the death spiral, so my code never got to the point where I could actually set up the LCD controller registers.
I need the USB to be active before the LCD is up and running, so my workaround is to disable the USB interrupts while setting up the LCD pins and registers and then once they are done I re-enable the USB interrupts. That seems to work just fine.
It is unfortunate that this all happens kind of automagically. I don't see anyway to just disable the USB_OTG ATX interrupt (which is what USB_INT1 is tied to), so it appears I need to fully disable all USB interrupts until the LCD controller has been setup to actually use LCDVD[21]. Once the LCD controller is setup, it looks like the USB interrupt controller realizes that USB_INT1 is not to be used as an input.
Hopefully someone else can learn from my pain. Thanks.