UF2 update over USB on STM32H743: erasing inactive Bank causes host reset, but adding a Hub helps. Why?

[jay_chen]

Hi everyone,

I'm using an STM32H743 in USB device mode as a virtual USB drive (UF2 protocol) for firmware upgrade.

• Main program runs in Bank 1

• Upgrade firmware is written to Bank 2

During the file copy process (from PC to the virtual UF2 disk), the USB connection drops unexpectedly (host resets the bus, captured by USB analyzer).
However, if I connect the device through a USB Hub, the success rate improves dramatically.

I understand that in dual-bank Flash architecture, erasing or programming Bank 2 should not interfere with:

• USB peripheral operation (running from Bank 1)

• AHB bus access

• Interrupt latency (if properly configured)

But my test shows the opposite:

• Direct connection → frequent host reset

• Via Hub → mostly works fine

Questions:

1. What could cause the host to reset the bus when only the inactive Bank is being erased/programmed?

2. Why does adding a Hub improve reliability — is it signal integrity, power filtering, or host timing tolerance?

3. Could Flash write/erase temporarily block USB interrupt responses long enough to trigger a host reset?

4. Any recommended software workarounds (e.g., temporary disconnection, bulk-only transport handling, or endpoint stall before Flash operation)?

Environment:

• MCU: STM32H743 (Dual Bank mode enabled)

• USB: Full Speed / High Speed (both tested)

• Host: Windows 10/Linux

• Protocol: UF2 (MSC class)

Thanks in advance for any insights.

[Pavel A.]

>  (host resets the bus, captured by USB analyzer)

What are the last USB transactions before the host gets upset and resets?

 

 

[mƎALLEm]

​@jay_chen welcome to the ST community,

Please don’t duplicate threads for the same question in the community.

I’ve already removed the other post.

Thank you for your understanding.

[FBL]

Hi ​@jay_chen 

Thank you for the detailed question.

Flash erase/write on bank 2 can cause supply noise and temporary voltage drops that stall the CPU which can delay USB ISR. Even though bank 2 shouldn't theoretically interfere with bank 1's where USB peripheral code is located, the electrical disturbance during erase/write cycles can trigger timing violations that cause the USB host to reset the bus.

You can mitigate this by relocating your USB callbacks and critical code to RAM.

Yess, inserting a hub can mask this instability created by this disturbance in timing and electrically. Or, maybe, you can improve signal integrity.

[jay_chen]

hi：

I tried placing the program into 0x24000000 to run, but the issue still occurs. Are there any other methods to try?