USBD_CUSTOM_HID_REPORT_DESC_SIZE less than actual defined Report Descriptor

[FLast.3.72]

I'm porting some fully functional older CMSIS firmware to STMCube and TrueStudio. The old report is 363 bytes which compiles, but Windows Device Manager detects an error in the Report Descriptor. After some tinkering, setting USBD_CUSTOM_HID_REPORT_DESC_SIZE to 361 solved the problem, and the Device Manager error disappeared with the device correctly identified.

I suspect its related to the __ALIGN_END macro (== aligned(4)). Values of 362 fail, and 360 gives expected compile errors.

Looking at the USB HID mouse/kbd sample app, its Report Descriptor is 74 bytes, and it does not have the problem.

Anyone have some ideas why USBD_CUSTOM_HID_REPORT_DESC_SIZE has to be 2 bytes less that the actual size?

[Pavel A.]

> I suspect its related to the __ALIGN_END macro

If this code is based on a ST example, I'd rather look at the array size definition. In the ST examples the size of descriptors is often defined as a "magic" constants rather than sizeof(array).

-- pa

[FLast.3.72]

Pavel, thanks for the reply. The generated array size definition code is

__ALIGN_BEGIN static uint8_t CUSTOM_HID_ReportDesc_FS[USBD_CUSTOM_HID_REPORT_DESC_SIZE] __ALIGN_END ={...}

and for USBD_CUSTOM_HID_REPORT_DESC_SIZE = 361, 362 and 363, as I understand the aligned(4) macro, sizeof( CUSTOM_HID_ReportDesc_FS) generates the same value of 364. Correct me if I am wrong. What's weird is that the code compiles and the device enumerates correctly. And yet only 361 enumerates the device.

What's even weirder is the USB HID mouse/kbd sample app, its Report Descriptor is declared 74 bytes, and contains 74 bytes. I'd really prefer to find the explanation than start using magic numbers. e.g. actual_byte_count -2

[Pavel A.]

> sizeof( CUSTOM_HID_ReportDesc_FS) generates the same value of 364.

Of course, if you declare it as "uint8_t CUSTOM_HID_ReportDesc_FS[364]" sizeof will be 364.

What I mean, declare it as uint8_t CUSTOM_HID_ReportDesc_FS[] = { .... data.... }

so the size will adapt to actual size of the data. Of course, keep the alignment of the start address.

-- pa

[FLast.3.72]

OK, found it, my error. After pasting the old descriptor into the MX code, an edit deleted 2 bytes from one of the reports. All is now well.

Lesson learned: make sure the byte count is correct, and edit carefully. Sigh!