AnsweredAssumed Answered

USBD_API->hw->Init() will fail by garbage beyond the end of USB_FsConfigDescriptor[]

Question asked by Shige URATAN on Jun 28, 2020
Latest reply on Jul 14, 2020 by Alexis Andalon

Hi.

 

I'm testing LPC11U35FHI33/501, now about USB-ROM driver
with the example of 'nxp_lpcxpresso_11u37_usbd_rom_composite' from
lpcopen_v2_03_lpcxpresso_nxp_lpcxpresso_11u37h.zip.

 

The sample works well, but I've noticed that some garbage following
USB_FsConfigDescriptor[] can make USBD_API->hw->Init() to fail.
(The marking on my chip is "0 11U35 / Z 57 02 / 4492A50")

 

Let me show the sample case.

 

CASE I

 

Change the 'Terminator' description of USB_FsConfigDescriptor[]
in composite_desc.c like below,
then USBD_API->hw->Init() will fail with ERR_USBD_BAD_EP_DESC.

+-------------------------------------------------
| /* Terminator */
| 0 /* bLength */
+-------------------------------------------------
  | | |
  V V V
+-------------------------------------------------
| /* Terminator */
|// 0 /* bLength */
| 0x00, 0x05, 0x85, 0x00, 0x00, 0x00, 0x00
+-------------------------------------------------

First 0x00 shall be the terminator, but by second 0x05,
Init() may continue to process it as USB_ENDPOINT_DESCRIPTOR,
then may sense third 0x85 as bEndpointAddress,
and will fail if it is out of usb_param.max_num_ep.

 

CASE II

 

Change the 'Terminator' description of USB_FsConfigDescriptor[]
in composite_desc.c like below,
then USBD_API->hw->Init() will fail with ERR_USBD_BAD_MEM_BUF.

+-------------------------------------------------
| /* Terminator */
| 0 /* bLength */
+-------------------------------------------------
  | | |
  V V V
+-------------------------------------------------
| /* Terminator */
|// 0 /* bLength */
| 0x00, 0x05, 0x01, 0x00, 0x00, 0x0B, 0x00
+-------------------------------------------------

First 0x00 shall be the terminator, but by second 0x05,
Init() may continue to process it as USB_ENDPOINT_DESCRIPTOR,
then may sense 0x00,0x0B (0x0B00) as wMaxPacketSize,
and will fail if it will not satisfy usb_param.mem_size.


How can I terminate USB_FsConfigDescriptor[] TRULY and *completely* ?

(I did not investigate about any types other than USB_ENDPOINT_DESCRIPTOR.)


Further more, I think, this is the real reason that
"only USB_FsConfigDescriptor[] don't have modifier 'const'".

 

(We normally don't care what other constant-data will be placed
just after USB_FsConfigDescriptor[], only the linker knows.)

 

Again, how can I terminate USB_FsConfigDescriptor[] TRULY and *completely* ?

Outcomes