Enabling RTT in VSCode launch.json results in unstable debugger behaviour and experience

[jerrywrice]

I followed the 'official' probe-rs debugger online documentation for setting up my rust VSCode project. The online docs show a launch.json section with entry settings that enabled RTT. While I've used other embedded debuggers (multiple in-fact), this was my first exposure to probe-rs (and I'm unfamiliar with RTT). Following these docs initially led to successfully loading/flashing my compiled embassy STM32 rust code to my Nucleo STM32F091RC dev-board. Then things went wrong. The target code initially started and ran, but unfortunately exhibited quite erratic behavior and faulty behavior. This is target code which I had previously tested and verified using other tools. This led to many hours of further examining the online probe-rs documents, and posting for feedback on the rust embassy matrix forum. After finding a couple of probe-rs code samples on other sites, it appeared that rust application code should (must?) be modified to make use of certain RTT features. I then chose to update my VSCode launch.json config section to remove/disable the RTT stuff. After this I reloaded by target code and the flakiness and erratic behavior seen previously was resolved!

IMO the installation documents, especially as it concerns the example VSCode launch.json configuration text shown with RTT enabled, should be revised to include very explicit and clear warnings within the inline comments of the example launch.json config section text 'to NOT enable RTT unless certain x/y/z preconditions are met'.

[noppej]

I am not aware of any specific preconditions that need to be met. Can you please provide details on what "preconditions" and "rust application should be modified" you found affected your use case?