stm32l0xx, USB Custom HID with firmware 1.12.1 send report problem:

[HAHA]

USBD_CUSTOM_HID_SendReport(...) returns USBD_OK but nothing being send when code is generated with firmware version 1.12.1, but this function works without any problem in firmware 1.12.0

[Imen.D]

Hello @HAHA​,

Can you please confirm that you have the same issue as reported in this post1, post2?

Please try the proposal fix and I'll be waiting for your feedback.

Imen

[HAHA]

Post1 seems to be the solution. I confirm that version 1.12.0 that works correctly uses HAL_PCD_EP_Transmit(...) and the version 1.12.1 that does not work uses HAL_PCD_EP_DB_Transmit (...).

[Imen.D]

Hi @HAHA​ ,

In the release note of STM32CubeL0 version 1.12.1, there is this message:

HAL USB_FS update

HAL PCD: add fix transfer complete for IN Interrupt transaction in single buffer mode.

For customHID user should not use HAL_PCD_EP_DB_Transmit this is specific for ISO and bulk transfers not Interrupt.

I escalated your feedback internally for check within an Internal ticket number: 139848.

(PS: This tracking number (139848) is only for reference and is not accessible or usable by customers).

When your question is answered, please close this topic by choosing Select as Best. This will help other users find that answer faster.

Imen

[HAHA]

Hi Imen,

the issue is reproduced when the code is generated with STM32CubeMX.

HA.

[Imen.D]

Hi @HAHA​ ,

Thanks for this detail.

So, the issue is with STM32CubeMx. I will escalate this to the appropriate team.

Thanks

Imen

[Imen.D]

Hello @HAHA​,

This issue is not reproduced on side CubeMx team.

Could you please provide the project (ioc file) to check this behavior.

Imen

[HAHA]

Hi Imen,

sorry for the delay, attached please find the whole sample project that shows the problem. The application is supposed to send an "a" as a keyboard stroke on startup. If you change the firmware to revision 1.12.0 this application works as it should.

let me know if you have any questions.

H.

[MStud.2]

Hello

I just ran into the same issue and would be very interested in seeing a proper fix in an official HAL release soon.

The solution proposed in post1 is working for me, however I cannot test if it doesn't break another transfer type.

To me it looks not like a clean solution.

If I look at the STM32WB HAL, the implementation changed again in the meantime,

fixing some other bugs.