Flashing
Firmware images can be loaded, inspected and written to an ECU from the workspace or a project. The same image and recipe model is used by scripts and by the UI.
Firmware images
- Supported input formats: raw binary (
.bin), Intel HEX (.hex,.ihex) and Motorola S-record (.srec). - A raw binary needs a base address; HEX and S-record carry addresses per block.
- The image model reports size, CRC-32 and the address blocks it contains.
- Images can be saved back to any supported format from a script.
Images live in <workspace>/firmware or <project>/firmware.
Recipes
A firmware recipe (.bmrcp) sits next to the image and describes how the image maps onto an ECU: which blocks belong to which memory region, the base address, and the operations that must run before and after the transfer. Keeping the recipe next to the project makes a flash reproducible instead of a sequence of manual requests.
Flashing from the UI or a script
- Vehicle-specific flashing windows are included in builds where that vehicle module is present. Restricted builds exclude those modules.
- The generic path is the Lua API:
bm.firmware.load,bm.ecu.download,bm.ecu.flash_begin,bm.ecu.flash,bm.ecu.flash_end. - Every request and response is logged; a failed transfer leaves the exact stopping step in the log.
Flashing can leave an ECU unusable if the image, address layout or session is wrong. Verify the image CRC, the target ECU and the power supply before starting. Keep a known-good image and a recovery procedure for the vehicle.
Availability
The flashing feature set depends on the build and on the project's vehicle module. The public download is the unrestricted core; vehicle-specific modules and recipes are distributed separately.