probe-rs run: Consider setting a breakpoint on main to synchronize RTT attach

[Tiwalun]

probe-run does set a breakpoint on main, and attaches to RTT after that breakpoint is hit. probe-rs-cli currently tries to attach repeatedly.

I'm not sure if we consciously decided to take a different approach, so if anybody knows feel free to explain here and close this.

See https://github.com/knurling-rs/probe-run/blob/b4d99b621fc1de71cb2743fb10e015ff2905915b/src/main.rs#L311-L340

[noppej]

@Tiwalun If we break on main, before the user code executes, will it not be a case of the RTT control structures have not yet been configured?

[jamesmunns]

I think that's a good point on the difference between defmt-rtt and rtt-target - the former is statically configured (so it will be initialized by cortex-m-rt essentially before main starts), while the latter requires an explicit init call (after main starts).

[noppej]

That is a valuable distinction. Our handling and timing of attach should follow different paths then for the two.

I suspect this distinction might answer @Tiwalun 's question about "if we consciously decided to take a different approach".

[Tiwalun]

Now I'm just wondering why rtt-target actually need an explicit call 😄

[MabezDev]

Now I'm just wondering why rtt-target actually need an explicit call 😄

rtt-target works around the possibility of the debugger polling the rtt control block before its fully constructed. It does this by writing the segger string last. However, in practice, I'm not sure this workaround is entirely relevant because I don't think anyone has ever run into it. It might not be worth implementing this workaround, and falling back to how defmt initializes the control block.

[Yatekii]

It's actually a real world issue that we run into sometimes. But maybe if we do the breakpoint procedure we can mitigate it and get something more out of it even :)