We have an application that has been running for many years now based around the open source lpcusb library. This has been run successfully on LPC23xx, LPC17xx, LPC177x and LPC40xx processors. The USB device looks like a CDC to the extent necessary to work with the usbser.sys driver provided on Windows. We use the USB link as a byte stream with a message based protocol running on top of it and regularly see sustained bulk in data rates of ~600kbytes/sec, with no errors when run for days at a time.
I recently decided to try and migrate this to the USBD ROM API, which was somewhat painful due to the poor quality of the documentation, but with some digging I have managed to get it ported across. When running it shows bulk in data rates that are possibly better than with lpcusb, but has occassional data losses or corruptions that show as lost protocol messages even at low data rates.
I have been looking for a source of these errors but have failed to find a reason for them. Data to be sent is queued in a FIFO and we use the start of frame interrupt to determine when to start a chain of bulk in packets, after which additional packets are sent when a USB_EVT_IN event is seen. The chain is terminated by a short packet or zero length packet as required once the FIFO is emptied.
Structurally this is very similar to the lpcusb application and apart from one file that contains the USBD specific interface code is built from the same source base. Due to this I am able to run both versions of the code (lpcusb vs. USBD) on the same hardware and only have problems with the USBD based application. This is seen on both a custom LPC1769 board and an Embedded Artists LPC4088 quickstart board.
I've trawled through any relevant messages that I can find here, but have not found any answers. I am at the point where I wonder if I am tripping up on a bug in the ROM code? I've seen various references to ROM code bugs along the lines of 'artf45032 ROM driver BUG' - when can I find a list of these?
Any help would be greatly appreciates as moving forward I would like to be able to use the USBD API to avoid having to deal with the low level details of the actual target part.
Andy
