OpenMV-H7 Capture Failed: -4

OpenMV Products
#1

Hi,

Just received a new OpenMV-H7 bought through Mouser (so assume it’s genuine.)

Installed OpenMV IDE, plugged in the OpenMV board and connected fine. IDE asked to update the firmware, which I did.

After the green flashing of the bootloader, the LED rapidly flashes white. So I’ve tried reloading the firmware a couple of times with no luck.

I’ve tried running the helloworld example a number of times. Sometimes the ERROR.LOG file contains:
FATAL ERROR:
name too long

and main.py contains
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ

Sometimes the main.c contains something reasonable and ERROR.LOG contains:
FATAL ERROR:
Capture Failed: -4


I’m out of ideas of what to try next. Any ideas?

Thanks

#2

Seems like the firmware flashed incorrectly. Can you try updating the firmware again?

-4 means that no sensor was found. Can you check the camera connection to the main board.

#3

Thanks for the fast reply.

Yes it does look like a firmware load issue.

I’ve checked all the solder joints under the microscope and everything looks nice. Re-plugged the camera module a few times with no change (although it does detect when then camera module is not plugged in.)

I’ve loaded the firmware a few times through the IDE, but always the same result.

However I note the IDE believes 3.6.8 is the latest, but it seems you’ve released 3.6.9 in the last couple of days.

Perhaps I’ll try loading the firmware with an STLink and the ST tools so I can verify the image is loaded correctly.

Thanks for your help.

#4

Loaded 3.6.9 successfully.

Unfortunately though it looks like a hardware problem. Moving the camera module around allows it to sometimes get a single frame to the PC before having the “Capture Failed: -4” error.

Hopefully it’s just the camera module, as I have the Global Shutter camera module on its way. If that works then it’s all fine.

Unless there’s anything else you suggest I should try?

#5

Not really, if the hardware is broken then there’s not much you can do.

#6

So I have a resolution on this… and it’s important.

I’m considering integrating a number of in a system, so I doggedly wanted to find out what failure mode this device would have directly out of the box. I traced via and tracks, probed signals and everything looked ok (albeit the chopping off of half the via’s at the top of the board by the manufacturer I personally wouldn’t be happy with.)

But still very odd behavior of the whole device. So I probed all the power rails to see if something suspect was happening with decoupling, nope all looked good.

Then I remembered this post from the eevblog forum (I’ve used a number of STM32H7’s in designs.) STM32H7 series revision: Beware of the changes! - Page 1

And yep, turns out the OpenMV H7 I’ve got from Mouser has Y revision silicon. That means it is only good for 400MHz, so was effectively being over-clocked at 480MHz. I then rolled the firmware to V3.3.1, which is the one before the 480MHz change, and it works as expected.

So this is pretty important, you are right now shipping silicon that will NOT work past revision 3.3.1 of your firmware. There is an IDCODE byte that can be read by firmware to check what revision the device is. If it’s Y silicon and not V, then 400MHz is all it can do…

#7

So it looks like one can not even buy a new H743VIT6 anywhere at the moment to replace the old revision.

Sometime next month before any come into Mouser and Christmas before Digikey have any.

I’m guessing this shortage is why your manufacturer is using old silicon?

#8

We have to by from the factory. Generally, we have a 3 month lead-time on getting now parts.

#9

Mmm, okay, I see. This explains a lot. Yes, we overclocked all our boards to 480 MHz since all our models worked that we tested.

I’ll have Ibrahim fix this.

It’s weird however, since they pass testing before we ship them.

#10

Okay, I’ve asked Ibrahim to fix this. We’ll just not set the clock speed to 480 when it’s revision Y.

#11

I then rolled the firmware to V3.3.1, which is the one before the 480MHz change, and it works as expected.

A lot of things have changed since 3.3.1 it could be anything, anyway I’ll send you a firmware with 400MHz clock for testing later.

#12

True, it could be something else in your firmware. If you like I can try the firmware revision after the 480MHz change, to minimize the number of changes between the builds?

It’s a shame I don’t know what firmware revision it had from the factory.

#13

Very old, probably before 480MHz. This is starting to make a lot of sense…

#14

Hi, the attached firmware detects the revid and overrides the frequency if needed, can you please test it a let me know ?

Thanks.
firmware.zip (1.16 MB)

#15

After a limited amount of testing, that new firmware appears to work fine, where as the 3.9.0 Release firmware never worked once.

So certainly seems we’re on the right track.

Thanks

#16

Okay, this fix will be in the next release, thanks for helping.