Open sakian opened 1 year ago
Thank you for reporting. Do you have any solutions in mind. Would it help if we reset the RTT ID before running?
I haven't had much time to look at this recently. I've added a delay to probe-run which has significantly reduced how often this happens, but is obviously not a great solution. I'm hopeful that I can return to this issue at some point and give it more thought.
Describe the bug The target writes the control block to memory at init (
defmt-rtt
does this automatically,rtt-target
requires calling an init macro).probe-run
will load this control block from memory after flashing and starting the application.From what I can see, the only thing stopping
probe-run
from reading this control block before the target writes it is a read for the RTT ID at the top of the memory space (written last by the target), however, if there is a control block written to memory from a previous run,probe-run
might read this old control block before or while the target writes the new control block.This can cause unexpected behaviour like corrupted control block message during init or when trying to read from the RTT up channel, or outputting corrupted data (only seen when using defmt). Some examples are below.
To Reproduce Steps to reproduce the behaviour:
cargo run
Expected and observed behaviour Should output
Started
after flashingconfig.toml The contents of your project's
.cargo/config.toml
fileProbe details
Operating System: Windows 10