USB Device Driver - LPC responding to IN packets with zero-length data instead of NAKs.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

USB Device Driver - LPC responding to IN packets with zero-length data instead of NAKs.

619 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by KarlBuiter on Mon Mar 02 19:53:31 MST 2015
Got a USB Device Driver ;

I have interrupt endpoints (EP) configured as IN ( 0x83).

If I have data to send, the data is sent as part of an IN transfer -
The USB_Ctrl is set for Write Enable for the EP,  the length is set, the data is sent through the register, and made valid via SIE.
The resultant response is seen in the USB Analyzer logs... Looks good.

But when I have no data to send;
I see Zero-length data responses to the IN transfer.
There should be NAKs (if I understand this correctly).

Looking for some direction in what to look for.

This is on a LPC2468

TIA
Labels (1)
0 Kudos
2 Replies

551 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by KarlBuiter on Mon Mar 16 14:29:33 MST 2015

Nope, not from a bad example.  Though I do look at them.

The issue was using EP 3 as an Interrupt EP.   According to table 308 in the LPC 24XX Guide (Chap 13), EP 3 is set aside for Isochronous.  I suspect these assignments are processor specific and just was not aware of it here.  EP 3 was predefined for its use by other design criteria; we have been able to mitigate.

Thanks Tsuneo for your help.
0 Kudos

551 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Tsuneo on Sun Mar 08 10:21:19 MST 2015

Quote:
This is on a LPC2468



And where does the example come from?

Maybe, you've started on a "bad" HID device example, which repeatedly returns input reports over the HID interrupt IN endpoint at every IN transaction from host. HID spec supposes just when any change would occur, the device should return an input report. I've warned on this issue for these years, but sloppy programmers have still reproduced "bad" HID examples.

In most cases, "bad" HID example implements "bad" behavoir in these code sections,
- Set_Configuration handler: put an initial input report to the interrupt EP.
- The endpoint interrupt handler: put another input report to the interrupt EP.

Delete these codes from the example, and you'll see the behavoir you expect.

If you would specify the starting example, you would get more detailed answer.

Tsuneo
0 Kudos