Debugging OpenMV4 firmware

Hi community,

We are using OpenMV4 (with chip STM32H743VI) and are currently trying to debug (step, breakpoints, etc…) the firmware. We have tried all the approaches mentioned in this forum or else where online, without success so far.
Anyone has an official status on this? Is it possible? On Windows? On Linux (Ubuntu)?

Thanks in advance :smiley:
xvbv

Yes it’s possible, but you have to use the official ST tools because the opensource alternatives don’t fully support the H7 yet.

hey iabdalkader,

Thanks for your prompt reply! I guess you’re talking about the STM32CubeIDE. We have installed it and are able to debug the STM32H743 board, from a STM32 (“empty”) project. Now, do you have any tips on how to import the OpenMV project into STM32Cube’s project? It actually could be a very nice feature to have some project files in the OpenMV repository. Thus providing a fast way to get started with firmware development…
Another question: do you know if it’s possible to both debug the firmware code and launch the micro-python code from OpenMV IDE ?

On a side track, we’ve been debugging the .elf, generated by the Makefile in OpenMV, into an empty project in STM32CubeIDE. We can step through the code for a dozen of functions but then the debugging crashes. Same when RUNning the code. Have you seen similar behaviors?

Thanks in advance !

Because MicroPython didn’t make their code base compatible with STM32Cube our firmware is not compatible with STM32Cube.

hey Nyamekye,

I don’t mean to debug the micro-python from STM32Cube. Just wondering if OpenMV (USB connection) can run at the same time as debugging (the firmware-only) from STM32Cube (SWD connection) ?
Or do you mean that simply debugging the firmware is not possible in STM32Cube? (iabdalkader just mentionned that it was possible…).
The most important for us is to be able to debug, then we can simulate any command coming from the micro-python layer.

Anyways, what we see so far is that when running the code from Cube IDE, it throws this error after just 1-2 seconds : libusb: error [udev_hotplug_event] ignoring udev action bind. Our bet is that there is a power conflict on the OpenMV4 board. Can you comment on that ?
Or this error: failed to insert all hardware breakpoints you may have requested too many hardware breakpoints. Even though there is no breakpoints… Are there any “pre-programmed” breakpoints in the .elf file generated by OPenMV4.
Note that these two errors only happen when debugging the .elf from OpenMV. When compiling another project (of similar size) in STM32Cube, the debugging works perfectly fine!

Btw, these tests have been conducted with a ST-LINK/V2-ISOL and also a ST-LINK/V3. And OpenMV latest tag built with simple: “make all”.

We are considering to go down the path of importing the OpenMV project into STM32Cube (to facilitate (firmware only) development (debugging, pin configuration, etc…), what are your thoughts on that ?
Thanks !

Hi, um, so, I get that you are struggling through this… but, MicroPython has no hooks in it to integrate into STM32Cube. This is actually a pain for us too… but, me and Ibrahim mainly just debug the old school way using printf() and seeing that output in OpenMV IDE. You can use OpenMV IDE to load the firmware too.

If you want to use SWD debugging I guess you can too. I’ve never done it before however. That said, at my day job, I use a Segger debugger for projects with gdb. This works on STM32 chips.

Anyway, I don’t think you can easily use the current firmware setup with a nice single step debugger. Ibrahim may know more however.

We managed to make it work !
Key take-aways :

  • Use STM32Cube IDE, create empty STM32 project, use the .elf output from OpenMV in the debugger
  • Use external 5V (Vin)
  • Don’t connect USB plug
  • Use the python file on internal flash
  • Set a few breakpoints in main before the call to “exec_boot_script(”/main.py", false, true);" (apparently when running too big chunks of code, the debugger crashes)

Hello @xvbv I have the same issue like you. I have modified the source code and compiled but I am not able to get it worked. Firmware crashes somehow. I need to debug the firmware step by step.

Could you please share the cubeide project so that I do not waste time.

Best regarda

This is an old thread, FWIW I’ve switched to J-link base compact long time ago, I use it to debug the ST F4, F7, H7, nRF/CM4 etc…using their gdb server something like this:

# Run Jlink GDB server
JLinkGDBServer -if swd -halt -strict -cpu cortex-m -device STM32H743VI
# Connect with GDB
arm-none-eabi-gdb -ex "target remote localhost:2331" build/bin/firmware.elf

It works really great, I had no issues at all when debugging our firmware…Keep in mind you need to start with a clean build (make clean) and pass DEBUG=1 when building… for example:

make -j8 TARGET=OPENMV4 DEBUG=1

Hi @iabdalkader ,
Would you like to share more detail? I am developing something on your firmware … again … XD.
And after I write my sensor driver and run it, it seems work maybe… 1, 2 seconds, then it (OpenMV) is just hangs, not any respond, and in this time, I lost my printf messages (it seems hang too.), so I am hard to debug what is it happen. (this driver work fine on your old version firmware … 1 year ago…XD)
I only know that it may be hang on __WFI() …
Do you have any suggestion? Thanks.

You’re kinda on your own when editing the firmware.

However, you could try to add printf statements to your code edits and see what causes the issue and then ask us an educated question about something you don’t understand.

Right now you are basically saying that your code doesn’t work and giving asking no question about what is wrong…

@kwagyeman
I am sorry for my bad comment.
Here is the detail, I write a SPI sensor driver and init my sensor fine. And rely on your sensor_snapshot(), but it will hang on __WFI() after few frames.(I found this point by add some log messages.).
I put some printf debug message on DCMI_DMAConvCpltUser, but there is not any one be displayed… (OpenMV IDE show the framebuffer for almost 1 or 2 sec.)
For now, I don’t have any way to check what is happen, specially I don’t why the DCMI_DMAConvCpltUser() logs are not show…

I found a interesting information on MicroPython github…

But there is not any anser… XD

I will keep trying, thanks for your reasponse.
And I would appreciate it very much, if you can provide me any debug method (it seems printf is not enough).

Maybe I should print the debug log from Uart instead of USB … hmm …

If you are adding code to that function you probably should think about another way to do what you want. Touching anything in the frame grabbing pipeline requires a pretty extreme level of knowledge.

Note that that method is called like 10k+ times a second. You can’t print from it.

ya, you are right.
I think I may be fixed my problem but I am still checking.

And there is a suggestion about the framework.
You provide a chance to let sensor driver override the snapshot() cb function, and we know DCMI is almost always depends on DMA, but your DMA cb (DCMI_DMAConvCpltUser) is be fixed on STM32 HAL (stm32h7xx_hal_dcmi.c ).
Maybe it should also provide a chance to be override by sensor.
Acutally I have been doing this in my internal project because I have a sensor which is a little bit tricky… (I need to process every line…)

Thanks for your help and suggestion. :smiling_face_with_three_hearts:

Ah, I see. Um… yeah, generally I’d avoid computation in that method since it has to complete fast.

Actually, there’s one big improvement coming to our firmware soon where I will use MDMA to entirely offload the capture so that the processor is not calling that per line.

1 Like