I’m working on modifying the firmware for an OpenMV Cam H7 Plus and I want to make sure I’m following the recommended development workflow before going deeper.
My goal is to modify the image processing algorithm inside:
openmv/lib/imlib/phasecorrelation.c
Then rebuild and flash that custom firmware into the OpenMV H7 Plus using OpenMV IDE.
Before proceeding, I’d like to confirm a few things from the maintainers:
Recommended build workflow
Is the Docker-based build (openmv/docker, make TARGET=OPENMV4P) Currently the preferred method for firmware development?
Or should I use the native Linux toolchain setup?
Submodules/cloning
Is cloning with --recursive the correct approach for firmware development?
Are there any additional setup steps required to ensure all dependencies are correctly initialized?
Rebuild behavior
When modifying files inside imlib, is a normal rebuild sufficient, or is a full clean build recommended to avoid cached objects?
Algorithm modification considerations
Are there constraints I should be aware of when modifying phase correlation (e.g., memory layout, DMA buffers, frame buffer ownership, or timing assumptions)?
Any guidelines to ensure compatibility with existing OpenMV image objects and MicroPython bindings?
Best debugging approach
What is the recommended way to debug or validate changes inside imlib? (printf over USB VCP, IDE debug output, or another method?)
I’m mainly trying to follow the same workflow used internally by OpenMV developers to avoid fighting build/environment issues while experimenting with algorithm changes.
We have an incremental build system. Only clean when changing board types.
Not really, just note that you generally want to use fballoc for buffer allocation.
Yeah, printfs which appear in the IDE is the easist way. You can use Tools→Load Custom firmware to load any firmware you want from the IDE. In your build folder this will be bin/firmware.bin. Alternatively, you setup a SWD connection and use the Cortex-M debugger in VS code to load a firmware.elf and single step the code. It’s a bit more setup… but, might be easier to debug with as you can add breakpoints and dump registers.
I’ve attached my cortex-m debugger file.
launch.json
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Cortex Debug",
"cwd": "${workspaceFolder}",
"executable": "${workspaceFolder}/build/bin/firmware.elf",
//"executable": "${workspaceFolder}/build/bin/bootloader.elf",
//"executable": "${workspaceFolder}/build/bin/firmware_M55_HP.elf",
//"executable": "${workspaceFolder}/lib/micropython/ports/stm32/build-OPENMV_N6/firmware.elf",
"request": "launch",
"type": "cortex-debug",
"runToEntryPoint": "main",
"servertype": "jlink",
"serverpath": "/opt/JLink_Linux_V880_x86_64/JLinkGDBServer",
"ipAddress": "192.168.4.177",
//"device": "STM32F427VG",
//"device": "STM32F765VI",
"device": "STM32H743VI",
//"device": "MIMXRT1062xxx6B",
//"device": "AE302F80F55D5_HP",
//"device": "STM32N657L0",
"interface": "swd",
}
]
}
Uncomment the correct target and executable to work with. Note that you need to compile with DEBUG=1 to get a binary that you can easily add breakpoints and single step.
Note that I use a remote server from WSL on my machine with segger jtag. If you are directly connected via linux, you don’t need the ipaddress part.
Thank you for your detailed support!
But I faced a problem when I was uploading my custom firmware via OpenMV IDE v4.8.6 (Tools → Load Custom Firmware).
Hi, the firmware needs to be named firmware.bin. Was it named something else? That error happens when the settings for the IDE aren’t configured correctly. I haven’t seen it in a while after fixing bugs with it.
Yes, it was named firmware.bin. But the problem is solved after this:
In the Tools menu, I unchecked the “Auto Reconnect to OpenMV Cam”, then I disconnected the camera session by pressing the disconnect icon button and closed the IDE (I wanted to make sure that the IDE is not connected to the machine COM and then open the IDE without attaching to the camera as the problem is related to the VID/PID of the DFU states [Is it bootloader or active application mode]).
After that, I plugged the camera back in and waited until Windows finished enumerating it, then I opened the IDE (without connecting to the camera) and used the “Load custom firmware” in the Tools menu and it started to load the firmware.bin file smoothly.
