No DEFMT output
Check DEFMT_LOG filter:
Filter levels in order from lowest to highest severity are: TRACE, DEBUG, INFO, WARN, ERROR
More info on DEFMT filtering levels here
This can be set multiple ways:
- If using
cargo runon a probe-rs based runner:ENV VARat build time:DEFMT_LOG=trace cargo build ...- In
.cargo/config.tomlNote: there is a bug in cargo that does not automatically recognize changes when rebuilding.[env]DEFMT_LOG = "trace"
- If using VSCode plugin,
- Make sure
rttEnabledistrueandconsoleLogLevelis set to appropriate filter level:{"version": "0.2.0","configurations": [{// SNIP..."coreConfigs": [{// SNIP ...,"rttEnabled": true}],"consoleLogLevel": "Console", //Console, Info, Debug}],}
- Make sure
Check memory.x file is correct:
- Make sure origin offsets are correct according to datasheet/ application
- Make sure lengths are correct according to datasheet/application
- Note: Lower values for RAM are OK, but values that exceed the chip’s spec will cause a crash and not allow RTT to connect.
Check correct Chip selected:
.cargo/config.tomlunder runner. Example:runner = "probe-rs run --chip STM32L451RCTx"- If using VSCode plugin in
launch.jsonconfigurations/chip{"version": "0.2.0","configurations": [{// SNIP..."chip": "STM32L451RCTx",// SNIP...}],}
Check defmt_rtt is being “used” in code:
If not, it will not be linked during compile. Example:
use defmt_rtt as _;On STM32 series chips, check the state of the BOOT0 pin:
- If BOOT0 is HIGH or floating, the core will run from internal bootloader instead of flashed firmware.
- BOOT0 should be pulled LOW for SWD programming, however even if it is HIGH or floating, programming may appear to succeed but firmware will not properly run.
Make sure tooling is up to date:
As with any set of tools being actively developed and improved, sometimes if one part is updated and there is a breaking change, the other tools must be updated as well in order to function.