Custom board issues

I’ve made two identical prototype boards on which part of each board hosts openmv H7 Plus circuits almost identical to your schematics. I was able to flash dfu and firmware with the ide on one board which works with the exception of the sensor communication which might be due to a Chinese copy dF12 connector which doesn’t seem to mate very well with the camera module. We are going to scope signals and debug.

It may also be that with the oscillator the caps need to be tuned to our board’s stray capacitance.

On the other identical board the ide loaded the bootloader.DFU but after flashing dfu-util exited with error code 71. I read that it happens sometimes and shouldn’t be a problem so I flashed firmware.dfu.

The process gets stuck halfway and just hangs at around 40% completion.

I am suspecting that some if the chips I bought on Alibaba may be faulty. If so which should I suspect ? The STM only or also other chips involved in the process of flashing firmware.dfu?

In general any tips on either of the issues? In production do you often find such issues? Thanks.

No this doesn’t normally happen, there’s an issue with dfu-util with H7 Rev-V chips that makes it fail when loading bigger firmware images (that span banks). The bootloader.dfu should load normally.

This is the dfu-util issue mentioned above likely.

No idea, maybe a power issue, I would use original chips from a known distributor if I were you, and no issues at production we use SWD in production to flash multiple cams with the factory firmware.

Thanks. Yeah I would have liked to use chips from an authorized distributor for the prototype boards but long lead times.

Just to be sure you are suspecting that our issue is that we have Rev V chips or that some power supply issue may be causing dfu-util to not flash bootloader correctly?

You can check the markings on the chips to confirm, if you manage to flash the bootloader, you can use the bootloader itself to load the firmware instead of dfu.

Marking of the chip on the board that works : STM32H743IIK6
7BA6F VQ
PHL 78 020

The other set is at my designers place I can find out later but I bought them together.

By flashing the boot loader do you mean with the IDE Tools flashing the boot loader.dfu?
How to use the boot loader itself to load the firmware?

I think it’s a rev v device, you should check the datasheet to confirm, the rev marking location is different based on the package type.

I meant upload the bootloader.dfu with dfu-util first (with the IDE or from the command line) then reset the board, it should flash green quickly and keep resetting or get stuck, then you can use the bootloader to load the firmware (from tools->run bootloader) run it first and then disconnect/connect the usb cable.

You know what as a last resort, if all fails you should try to upload the bootloader + firmware using the official ST dfu tool (can’t remember it’s name stcubeprog I think ?), it works with all revisions…

Thanks . I will try and let you know.

Is this the tool? STM32CubeProg - STM32CubeProgrammer software for all STM32 - STMicroelectronics

Can go directly through USB or do I need a programmer ?

Yes I think so and yes. If you get into any issues with that you should ask on ST’s forums.

1 Like

To load with the tool I need to know where the Firmware starts in the memory. Do you know which address?

The bootloader starts at the base address and the main firmware image address is in the board config files (MAIN_APP_ADDR)

Non chance with Openmv IDE (firmware flashing always hangs at 44%) but STMcubeprog worked a charm. Some instability that I never noticed with your boards but will try to figure out why.

I’d be glad if you could take a look to my other post about the Global shutter signal names not matching the H7 plus ones to the DF12 on your schematics.

Thanks. This issues is solved.