Custom openmv.dfu file flashing issue - Poll timeout 1000 ms

Hey you guys, I have a very annoying problem here that is causing a drastic slow down in development.

Previous Success
I have made a custom PCB that us based on the OpenMV 4Plus. I customized various files in the Micropython library and had the first version of the board working just fine. I would use DFU Util to flash the custom firmware (like the OpenMV DFU Tool uses) and everything went great.

Current Problem
After altering external components on the PCB and ordering a few more boards for testing, this new board seems to have an issue with flashing the openmv.dfu file that originally worked. When using DFU Util to flash the new firmware, it stops at 57% while erasing memory block 2. Here is the DFU Util command and output with -v parameter to show more information:

/Applications/OpenMV -w -d , -a 0 -s :leave -D /…/openmv.dfu -v -v
Erasing page size 131072 at address 0x080c0000, page starting at 0x080c0000
Poll timeout 1000 ms
Poll timeout 0 ms
Erasing page size 131072 at address 0x080e0000, page starting at 0x080e0000
Poll timeout 1000 ms
Poll timeout 0 ms
Erasing page size 131072 at address 0x08100000, page starting at 0x08100000
Poll timeout 1000 ms
Poll timeout 1000 ms
Poll timeout 1000 ms
Poll timeout 1000 ms

This command had worked fine on the previous PCB changes and I am not sure if it is occurring now due to a change in the STM32H7 processor or maybe its something else entirely.

My Further Research
I reached out to ST to get some advice on this issue and they recommended I use their flashing tool: STMCubeProgrammer. I played around with the software and was successful in flashing the firmware by downloading/installing the firmware.elf and bootloader.elf files that are output during the ‘make TARGET’ command as outlined by the OpenMV Firmware Guide. The script runs on boot and has no issues until the board is powered off or rebooted. When this happens, any files I add to the board using the Flash Drive storage that pops up when connecting via micro-usb is erased from the board and the original files (given by the firmware) are the only ones to be found.

My Final Questions

  1. Has anyone experienced or potentially knows why the DFU Util tool would be stalling during the erase phase at 57% or memory address 0x08100000. And if so do you have a solution?
  2. After successfully downloading the firmware.elf and bootloader.elf files, why would the board be re-formatting the Flash Drive memory?

Some Pictures
Here is the STMCubeProgrammer Tool

DFU Util Output (not verbose)

DFU Util Output (verbose -v -v)

DFU doesn’t work on the new versions of the STM32H7. In particular, ST changed the system firmware bootloader that’s in system ROM. This issue happens on the non-STM32H743VIT6 pcakage.

There’s no fix for this. All you can do is load the bootloader.dfu file and then switch to loading the firmware.bin file using OpenMV IDE.

If you print out the DFU target information using --list you can actually see the DFU device descriptor strings and version number have changed too.

ST cube formats the entire flash. It does not skip not writing to the USB flash drive areas.

You are free to use their tools… however, we cannot package them as the programmer is 400+ MBs. Bigger than OpenMV IDE.

My development flow is to load the OpenMV Cam using OpenMV IDE. I do not suggest using DFU from the command line.

You can mount the binary output dir in your host OS and then OpenMV IDE can see new binaries as you compile them. This is what I do.

First of all - that was such a fast response so thank you SO much for replying, you are so much faster than ST and more helpful haha.

The board I am currently using does have the STM32H743VIT6, maybe I should have emphasized that. So could it be a different problem all together?

I will definitely stick to the OpenMV Dfu tool instead.

With this issue, is there no way of me dragging and dropping a new script to the board without it being erased on boot?

I have other files I will be adding that are dependent on the board, and it would make things much easier if i did not have to include them in the firmware.bin file

The issue is just related to the newest silicon of the ST chip. You can check the bootloader dfu version to see chips that will have the issue.

Just use the IDE to flash the firmware.bin file with our bootloader flashed using bootloader.dfu.

Do you think this will keep happening with all the new versions of STM32 chips? Really sucks the flash memory gets erased on boot :frowning:

That only happens once. Only load the firmware.bin chip. And unselect the erase flash drive button in the IDE when loading.

After loading the bootloader.dfu and firmware.bin through openMV IDE the flash memory still resets itself whenever rebooting. Any idea why this might be happening? And if not is there any way I could pay you for some time to go through some debugging with me?

The flash would only do that if it’s corrupt. The firmware automatically reflashes the disk if it’s not readable.

What customizations did you make that would causes the main disk to be corrupted?

Also, are you writing files to the main disk during program execution?

Finally, if you put your firmware on the regular OpenMV Cam does this problem happen?

So I successfully found a workaround to the DFU flashing issue if anyone is having the problem.

In the OpenMV git directory there is a python file named “” in the following location:


if you run this script it will use a process similar to what is used in the OpenMV IDE and will successfully flash your board with the command:

python3 ~OPEN_MV_DIR/src/micropython/tools/ -m -u DFU_PATH.dfu

you must fill in the variables with the proper directory but it will flash the STM32 properly!