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 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?
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 ?
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.
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.
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).
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…)