CubeMX USB Custom HID code generation bug

[Gavin Baker]

Posted on December 08, 2017 at 05:49

Pretty sure this is a codegen bug in CubeMX v4.23.0 with latest libraries.

To reproduce: start a fresh project, select STM32F103, enable USB, choose Custom HID Device, press Generate. When run, this generates a hard fault.

We see that the 'user string' feature is enabled by default:

C:\Temp\Test\Inc\usbd_conf.h:

83 &sharpdefine USBD_SUPPORT_USER_STRING 1

And this results in an additional callback added to the end of 

USBD_ClassTypeDef

:

C:\Temp\Test\Middlewares\ST\STM32_USB_Device_Library\Core\Inc\usbd_def.h:

177 uint8_t *(*GetOtherSpeedConfigDescriptor)(uint16_t *length); 178 uint8_t *(*GetDeviceQualifierDescriptor)(uint16_t *length); 179: &sharpif (USBD_SUPPORT_USER_STRING == 1) 180 uint8_t *(*GetUsrStrDescriptor)(struct _USBD_HandleTypeDef *pdev ,uint8_t index, uint16_t *length); 181 &sharpendif

This is used during enumeration, where the hard fault is triggered when the device is plugged in to the host:

C:\Temp\Test\Middlewares\ST\STM32_USB_Device_Library\Core\Src\usbd_ctlreq.c:

388 389 default: 390: &sharpif (USBD_SUPPORT_USER_STRING == 1) 391 pbuf = pdev->pClass->GetUsrStrDescriptor(pdev, (req->wValue) , &len); 392 break;

The code faults here because this function pointer is zero when it tries to branch.

The origin of the fault is explained by the fact that this additional field is not initialised when the callbacks are defined, and is thus zero due to partial initialisation (the member should appear after line 132):

C:\Temp\Test\Middlewares\ST\STM32_USB_Device_Library\Class\CustomHID\Src\usbd_customhid.c:

132 USBD_CUSTOM_HID_GetDeviceQualifierDesc,133 };

Disabling this feature by changing the &sharpdefine at top fixes the problem and the device enumerates and functions correctly.

I hope this is enough info to reproduce for a fix.

Regards -

  :: Gavin

#usb-device #usb-hid #hard-fault #code-generation #cube-mx

[johan239955]

Posted on January 25, 2018 at 14:40

Dear Gavin,

I had found the same issues and more see

https://community.st.com/0D70X000006SmC8SAK

ST has answered my post that they will implement improvements with the upcoming releases (>4.24)

[Gavin Baker]

Posted on February 02, 2018 at 01:01

Thanks, Johan - good to hear. I really wish there was a proper public-facing bug database though. It's far from ideal to have to trawl around message boards to find bug reports mixed with discussions.

The 'custom HID' codegen is barely usable too. I've had to make significant patches to implement it properly. I should probably write a post describing the changes...

[Tesla DeLorean]

Posted on February 02, 2018 at 04:13

>>I really wish there was a proper public-facing bug database though.

Even a read-only view so we can see what bugs and tickets are out there would be immensely helpful. Not sure ST is ready to let us see how the sausage is made, with internal debates/arguments, but having some central means of submitting issues would also be helpful, and some check boxes indicating the product families effected.

I'd like to see some 'Linus' equivalent with some clear and decisive views about things, and what's acceptable to ship and a top-to-bottom grasp of what's being delivered. Without some visibility about who leads/follows its hard to know how to tailor bug reports and code patches to optimize the process.

Right now we seem to be fighting a lot of time wasting problems which some thorough testing would clear up quickly.

The forum clouds things, we have too many 'me too' response for things which aren't necessarily the same thing, and multiple threads weeks apart which are the same issues recurring. Without some more active management and a centralized resource we are going to keep seeing that.

[Rob.Riggs]

This defect still exists in Cube 4.26.1 with L4 1.12.0 libraries. Even though the Cube UI says USBD_SUPPORT_USER_STRING is disabled, I see this in the generated code:

#define USBD_SUPPORT_USER_STRING   1

This leads to this compiler warning:

missing initializer for field 'GetUsrStrDescriptor' of 'USBD_ClassTypeDef {aka struct _Device_cb}' [-Wmissing-field-initializers]

And then broken CDC behavior.

Can someone from ST please confirm that this is a recognized defect and that it is being addressed?