Content originally posted in LPCWare by mch0 on Mon Sep 01 07:26:14 MST 2014
Hi,
I have opened another topic since I believe there is another problem with the USB ROM HID, but this time in the firmware, not the application example.
The problem seems to be that the FW does not correctly prime an endpoint if it is set to a max pack. length of 1024.
This is allowed in HS mode for INT endpoints.
Up to 1023 bytes it works.
I have traced it down (I think) to this:
In the queue header data structure the first entry is the "endpoint capabilities/characteristics" word.
Bits 16-26 reflect the max. packet size, these are 11 bits and the UM states, that the value must be <=1024.
This is fine so far.
However, when the USB ROM API initializes this field it seems to mask off bit 26.
Therefore values from 0-0x3ff (0-1023) will be set correctly from the associated EP descriptor.
However, if the EP descriptor indicates 1024 bytes (0x400), then this field gets initialized to 0x0 in the DQH.
As a consequence a packet is still ACKed by the primed EP (USB bus analyzer shows that), but no bytes will be moved out of the FIFO, probably because none have been stored anyway by the HW.
Test/Fix:
To test this, I have manually set this field in the DQH to 0x400 before letting the ROM API priming the EP.
Fortunately this modification survives the priming, because the ROM API does not touch the field after it has set it (incorrectly?).
Result:
Now it works again, that is, the test packet is not only ACKed but also the content is there ...
So the USB HW indeed allows all 11 bits to be used, it's just the FW that masks the MSB off.
Can someone at NXP please look at the sources of the ROM API FW to verify that behaviour?
Best regards,
Mike
