Closed gernoteger closed 2 years ago
Hi @gernoteger, Thank you for filing the issue. Could you please share how exactly you invoked probe-run
? And what is your probe-run version?
Hi @Urhengulas, thanks for the fast reply. I checked out v0.2.6 and commented out Lines 211-217; after build & install I invoked:
probe-run --chip STM32F446ZETx --verbose --no-flash ${BINFILE_DEBUG}.elf
This was just intended to be a proof of concept for me if it would work.
From looking into the code I don't understand what could be the reason for this restriction apart from guaranteeing consistency for the rtt_buffer_address.
defmt
logs are binary encoded and the decoding "dictionary" is stored in the ELF file, not the target's Flash. The Flash only contains the "keys" into dictionary.
The issue is that there's currently no "versioning", or checksuming done, to verify that what's on the Flash matches the ELF file one has at hand so allowing this combination of --no-flash
and --defmt
could lead to a silent "version mismatch" if you modify your program, recompile but don't re-flash it.
In the best case, a version mismatch would fail early on in the decoding process without any feedback on how to fix the issue; in the worst case, decoding would work but the log messages would be wrong, e.g. INFO the answer is 42
could become ERROR the answer was not 42
.
I think this versioning issue has been mentioned somewhere else in the issue tracker. Fixing it would also be required to support offline storage of (binary encoded) defmt logs.
after PR #303, which is part of probe-run
v0.3.3, this is allowed but prints a warning.
using probe-run with --no-flash shows:
It would be immensely helpful to just probe-run without flashing. From looking into the code I don't understand what could be the reason for this restriction apart from guaranteeing consistency for the rtt_buffer_address. A quick local test showed that at least in my setup, that is an STLINK V3 Probe + an STM32f446 based board, it worked nicely. Could this be enabled?