lpcware

LPCUSBLib Generic HID ROM Driver Bugs

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Jun 15, 2016 by lpcware
Content originally posted in LPCWare by neilt6 on Wed Jul 17 14:19:32 MST 2013
I've just spent an enraging 2 full days trying to get a generic HID device to work properly on an LPC11U35 using the on-chip ROM drivers with LPCUSBLib... In that time I've encountered so many bugs, and glitches, and "things that make you go hmm", it's not even funny. Before I start ranting, I should mention I'm doing the same thing on an ATmega32U4 running LUFA (Which LPCUSBLib is based on), and it works just fine. I'll start from the beginning:

First I created a new workspace and imported the LPC11U14 USB examples. Compiled the GenericHID example unmodified, 14KB later, surprise it works, so I move on to enabling the ROM drivers. This is where the fun starts... The first thing I did was change device symbol on all the projects to __LPC11U2X_3X__, then I changed the MCU selection to LPC11U35/401, and finally changed USE_USB_ROM_STACK to 1, crossed my fingers, and hit Build. CRASH, BOOM, BANG, undefined reference to `Generic_HID_Interface'! Hmm... So I tried building the other examples, most of them failed, but the CDC example built ok. Turns out, Generic_HID_Interface has been declared "static"... So I fixed that, and now it builds and runs. Hooray I thought, progress! So I opened up HIDClient.exe, and starting spamming things. Sigh... The button report won't work... I scratched my head over this one for a while, and ended up comparing the example to the older one that came with nxpUSBlib. Turns out GenericReport, DeviceDescriptor, and ConfigurationDescriptor are supposed to be "const"... So I changed those in Descriptors.c, and UsbRom.c, rebuilt, and tried it again. This time everything seemed to work, or so I thought. This is where things start getting really weird... The ATmega32U4 I'm replacing is using 64 byte reports, so I changed GENERIC_EPSIZE, and GENERIC_REPORT_SIZE to 64 in Descriptors.h, and rebuilt. Windows no longer receives the product string! Instead, HIDClient.exe lists it as "Device 1". Both reports still work though, so I rebuilt it using the software drivers. Windows now recognizes the product string, but the LED report no longer works, or at least, not all the time... And that's when I flipped the table over (figuratively speaking of course), and came here for help.

So the question is, what exactly am I doing wrong? Why have I had to make so many changes to the example just to get it to run properly, and how do I fix this new issue?

Outcomes