m33mu works well as a non-interactive firmware test runner. The most useful options for CI are:
--expect-bkpt--uart-stdout--timeout
Use firmware to signal success or failure with a BKPT instruction, route UART logs to stdout, and enforce a host-side timeout.
Example:
build/m33mu \
--uart-stdout \
--expect-bkpt 0x42 \
--timeout 10 \
tests/firmware/test-stm32h563/app.bin--expect-bkpt <imm> changes the process exit status so the run passes only if a BKPT with the requested immediate value is reached.
Behavior:
- exit
0if the expected BKPT is hit - exit
1if execution ends without hitting that BKPT
This is useful for firmware that intentionally reports “test passed” by executing a known breakpoint.
Example:
build/m33mu --expect-bkpt 0x7f tests/firmware/my-test.bin--uart-stdout sends UART output to stdout instead of exposing PTYs. This is usually what you want in CI because it makes logs visible in job output and easy to assert on.
Example:
build/m33mu --uart-stdout tests/firmware/my-test.bin | tee test.logNotes:
- this is intended for non-TUI usage
- when TUI is active, stdout UART routing is disabled
--timeout <seconds> installs a host-side execution timeout. If the timeout elapses, m33mu exits with code 127.
This protects CI jobs from hanging forever due to firmware deadlocks, infinite loops, or waiting for events that never arrive.
Example:
build/m33mu --timeout 15 tests/firmware/my-test.binPass/fail by BKPT and capture UART logs:
build/m33mu --uart-stdout --expect-bkpt 0x23 --timeout 20 firmware.binTrustZone split-image firmware test:
build/m33mu \
--uart-stdout \
--expect-bkpt 0x33 \
--timeout 20 \
secure.bin nonsecure.bin:0x2000Debug a failing CI case by enabling decode output:
build/m33mu --uart-stdout --timeout 20 --dump firmware.bin0: normal success, including the expected BKPT case1: argument or validation failure, or expected BKPT not hit when--expect-bkptis used127: timeout elapsed
- Prefer
--uart-stdoutin CI to avoid PTY handling. - Always set
--timeoutfor unattended jobs. - Reserve a dedicated BKPT immediate for “test passed” so your CI harness can detect success deterministically.
- When diagnosing failures, add
--gdb,--dump,--record, or--call-traceas needed.