extra OUT packet sent before IN packet on H2D control transfers - STM32G0

Strongato · ‎2026-05-21

Hello everyone,

I'm using the stm32G0 USB Host with firmware package V1.6.3.

There is an issue with H2D control transfers, where the USB Host stack send a second OUT packet before sending an IN packet on the last packet.

I wrote a usb dfu host class that uses USBH_CtlReq.

From this picture on the left we can see the PC sending a DNLOAD packet to the stm32h7, first the OUT packet followed by an IN packet.

On the right we can see the stm32G0 host sending an OUT packet followed by another OUT packet, before sending an IN packet. The device here is the stm32f4, which for some odd reason allows this (every single stm I tried allows this except h7, tested stm: F4, F7, G0, H5, L5). So my update actually works on every single stm except on the stm32h7.

But in the middle picture, the host is still stm32G0, but the device is an stm32h7, which after receiving the second OUT packets NAK's it.

From the picture, I would say that the stm32h7 is in the right here. It see that it got an OUT packet, which size was less than 64 bytes, and it expects an IN packet. That's exactly what the PC does, but not the stm32G0.

For some reason the stm32G0 sends another OUT packet before sending the IN packet, which is wrong.

I am providing a zip file with the .usb files, if anybody wants to take a look at this for themselves.

Kind regards,
Strongato

FBL · ‎2026-05-21

Hi @Strongato

Thank you for the investigation,

Could you please check whether the issue is still reproducible with the latest version stm32-mw-usb-host v3.5.4?

If possible, it would also be very helpful if you could attach a minimal firmware project that reproduces the behavior.

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Best regards,
FBL

Strongato · ‎2026-05-22

Hi @FBL,

I have provided you with the example code, this is proprietary software so only you:
https://github.com/FBLSTM

can access this github link:
https://github.com/Strongato-orqa/USBH_DFU_HOST_ORQA/blob/main/g0_example.zip

This is the comparison between PC and G0:

If you count the packets on G0 side, you will see that it sends 16*64 = 1024, and then it tries to send another one, which gets NAK'd.

I cannot reproduce this issue 100% of the time, sometimes it will pass normally:

The only difference I can see from these pictures, is when it does pass, all the packets are ACK'd.

I also tried to lower my MCU clock from 48MHz to 2MHz (just wanted to try something low), and all the runs passed. Could just be lucky, I'm not sure, but still, weird...

I am using the HSE bypass on my Nucleo board.

Kind regards,
Strongato