H7 Camera Board Bricked

It could be the pin headers or the jumper is broken or not making full contact. Can you try to short boot pin (from the bottom ) to the 3.3v pin on the header above the USB connector and using a different wire ? Note if the cam is flashing green when powered it means that our bootloader is running and it did not start in DFU mode, it also means the hardware is likely fine. If that still doesn’t work, I can only assume the USB connector is damaged somehow.

More info: If the firmware is somehow corrupted, you won’t see any USB device after the green LED flashing (after the bootloader jumps to the main fw), or it will get stuck in a boot loop. You will only briefly see a CDC device until the green LED finishes flashing at this point it jumps to the FW… If you do see the green flashing it means you can use the IDE to flash the firmware and you don’t need the DFU mode at all… To do so, you need to start flashing the firmware from the IDE first then connect the cam, the IDE should detect it and load the firmware.

So this is what you need to do, disconnect the cam and start the IDE and hit the connect button:

  • No OpenMV cams found
  • Do you have an OpenMV cam connected and it is bricked? → Yes
  • Please select the board type → OpenMV Cam H7 (STM32H743)
  • Erase the internal file system? → Yes
  • Disconnect your openMV and then reconnect it… Hit cancel to skip to DFU programming
    (At this point the IDE loads to no end) → You should see this:

Now connect the cam, the green LED flashes and the IDE will detect it and flash the firmware.

Hey, thanks for the lengthy reply.

Following your initial suggestion, I connected the boot to 3.3V from the bottom using two different jumpers and when powered on the board’s LEDs do not light up so I presume it’s entered DFU mode? However, in the device manager there is no sign of an ST/DFU device.

I then tried your second suggestion by starting the troubleshooting process on the IDE without the camera attached but when I plug it in, the green lights flash, followed by the white and then into the main script with a repeated blue light. Nothing changes on the IDE. image
It remains on this window indefinately.

Are you absolutely sure the USB cable has data wires ? It seems the cam is only getting power. Can you try the with any other board you may have just to confirm ? If it is working then the USB connector must be damaged somehow.

I’m unsure of how to determine if the cables have data wires however I’ve been using these cables for the last few months with this board and everything has been fine. In terms of trying on another board, I don’t have one with me at the moment to check. If it was in fact the USB connector, is there any trouble shooting I could do on my own?

It is definitely the USB cable (hopefully) or the USB connector, and you could try any other board or USB device and see the cable is working or not (but not by just powering it, it needs to have some USB function).

Hey team,

Since I was unable to get the board to connect I went out and purchased the H7 Cam R2. Straight out of the box it connected to the pc with ease. Seems like the USB header on my other board must’ve been damaged somehow. Is there any way of getting it fixed?

Um, can you see any damage? If this fails the camera is kinda done though. You might try to hot air rework.

No visible damage that I can see. Can’t recall a scenario that put the header in any harm either.

I’m not sure what to do. Did the board touch metal? They product doesn’t randomly die.

Can you verify that the 3.3V pin outputs 3.3V?

The only metal I’ve used around it would be the probes of my multimeter. And yes I can confirm that both 3.3V pins output 3.3V, and so does the reset pin.

Mmm, not sure what is wrong. Buy another H7 unit from our website and I’ll refund you the cost of it (not shipping)

I wasn’t able to obtain the same H7 Cam model as it is sold out but I have purcahsed the H7 R2 instead if that’s alright. And it terms of a refund, that would be really great thanks.

Please send me the order number.

I’ve just managed to brick one while updating firmware as well.

Developing on Ubuntu 20.04 running in vm on Ubuntu 20.04. IDE version 2.8.1
I have enabled USB in the VM for the openMV and DFU and can see in lsusb on the VM client OS.
Board is fresh from Adafruit. (OpenMV Cam H7 R2) (Sticker # 91102170 01251)

Initially, the Ide could see the board, but wanted the firmware upgraded.
So I tried the IDE firmware upgrade.
No joy, (hung in the download) so let IDE try with the DFU.

Exits from dfu-util with exit code 74.
show details says it could not find a file called …firmware/OPENMV4/openmv.dfu
That is correct, the .dfu version is not there or in the github releases.

So tried tools/runbootloader
download OPENMV4/bootloader.dfu
progress show a complete erase and download
but get exit code 74 from dfu-util
“Error during download get_status”

Hoping it still installed a good bootloader, I reboot without jumper and get a green flashing light

Using tools/runbootloader to download firmware.bin hangs
disconnecting and reconnecting does not start it

Reinstalling jumper and using tools/runbootloader to download firmware.dfu stops after erasing 44%

Given there are so many different issues, I suspect there is something about my dev environment.
Any suggestions?

I have a second unopened board, but given that they are hard to come by, don’t want to brick the second one.

Wait, is the light flashing green? This means the bootloader is fine.

Regarding the download… can you use a different computer? The IDE’s regular bootloader should never hang. That means something driver related is going wrong on your PC.

Thank you so much. It works. :ok_hand: :ok_hand: :ok_hand:

It’s alive!

After bricking when trying to update with the IDE on a Ubuntu client under VxWorks.

Downloaded ST’s programmer to the host Ubuntu system

copied bootloader.bin and firmware.bin from client to host
(They were at ~/.config/OpenMV/qtcreator/firmware/OPENMV4)

Shutdown VM so ST on the host could have the USB

Used ST to program and verify bootloader.bin at 0x8000000
Used ST to program and verify firmware.bin at 0x8040000

Stopped ST programmer, restarted openmv ide in the VM

Now IDE can see the hardware, is happy with the version, and can download and can see camera image on screen. (Yea!)

(There appear to be 2 repeatable, but minor bugs in the IDE.

  1. Can’t erase past block 44 when loading firmware.dfu
  2. Tries to down load a file which is not in the release. (openmv.dfu)

The DFU loader doesn’t work anymore for newer ST chips. It’s a can’t fix issue.

Regarding the missing file. That’s from our build process. @iabdalkader Should that file be generated?

No longer generated as it’s not needed, there’s a bootloader.dfu and firmware.dfu plus dfu-util is broken anyway.