Atmega32U4, Device Enum fails, Interrupts don't enable, free beer

[-N-]

Hello everyone,

First a thanks to this incredible open resource and support list. I
appreciate the hard work that has gone into making this a successful
module for device development. I am a hardware engineer making his
foray into advanced firmware, and I am tackling USB communications
because it sounded like a good idea at the time. I am using Dean's
LUFA 111009, and while the guts of the libraries are way over my head,
I think I finally understand my problem well enough to ask for
help. :) It may be a simple one, but here goes:

The chip in question is the Atmega32U4, running in Device Mode. I am
currently using test firmware, which is this reference firmware[1] by
Simon Inns. The symptom is Windows reporting "Device Enumeration
Failed", with all Device Descriptors reporting as 0x00 (including VID/
PID, which I think are Vendor ID and Product ID). Another symptom is
that the function Endpoint_IsSETUPReceived() is returning false.
(RXSTPI is always low.) Thus the USB_Device_ProcessControlRequest()
function is never called, and none of the actual functionality can be
enabled.

Stepping through the firmware, it seems the interrupts don't quite
enable. For example under USB_INT_HasOccurred, switch Interrupt ->
case USB_INT_SOFI: The statement return (UDINT & (1 << SOFI)); should
result in SOFI set high, but in the IO View of AVR Studio 5 SOFI
remains low. The same occurs for SUSPI, VBUSTI, and the other
interrupts in UEINTX. It seems the only enabled interrupt is WAKEUPI,
and that's how the PLL gets started (which seems to work, while (!
(USB_PLL_IsReady())) does not hang, FRZCLK goes low). The only event
handler I have is for ControlRequest events, so this doesn't help.

Mousing over USB_DeviceState I get 4, which corresponds to the
Configured device state. So it doesn't make sense that all the Device
Descriptors report as 0x00 to Windows. I do have a call to sei(); in
my main function, although it is after a call to USB_Init(); I don't
know if this makes a difference. I don't know what else to do here,
how to ensure the endpoints setup, or even if I am barking up the
right tree. If any of you understand what is going on, or even if it
sounds familiar, please let me know. If you live in SF, I will buy you
a beer!

Best regards,
Neel

[1] http://www.waitingforfriday.com/index.php/USB_Generic_HID_Open_Source_Framework_for_Atmel_AVR_and_Windows#ATmega32U4_Firmware

[Dean Camera]

Neel,

That's some extremely odd symptoms you are reporting; for the USB
device stack to get to the configured state, the host *must* have sent
at least one control request, so your breakpoint on
USB_Device_ProcessControlRequest() should have fired. What is in your
program's EVENT_USB_Device_ControlRequest() event handler? Since this
get the first go at control requests, it's possible your request
filtering isn't restrictive enough and you'd accidentally processing
device level requests in the user code and preventing the library from
being able to process them. The output of usbview.exe showing all the
descriptors as 0x00 is indicative that Windows didn't finish the
enumeration, and doesn't necessarily mean that the device descriptors
were not received or sent.

> Stepping through the firmware, it seems the interrupts don't quite
> enable. For example under USB_INT_HasOccurred, switch Interrupt ->
> case USB_INT_SOFI: The statement return (UDINT & (1 << SOFI)); should
> result in SOFI set high, but in the IO View of AVR Studio 5 SOFI
> remains low.

The statement "return (UDINT & (1 << SOFI))" is a test of the SOFI
flag, not code to set it - it should be set elsewhere instead. I
wouldn't try single-stepping the USB stack, as this is almost
guaranteed to make the communications timeout - try making the various
events of interest turn on a LED instead so that you aren't delaying
any packet processing.


Have you got a schematic of your board I can look at? Can you post
your complete code?


Cheers!
- Dean

> [1]http://www.waitingforfriday.com/index.php/USB_Generic_HID_Open_Source...