Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

probe-rs run leaves RTT in blocking mode when disconnecting #2425

Closed
9names opened this issue May 4, 2024 · 2 comments · Fixed by #2466
Closed

probe-rs run leaves RTT in blocking mode when disconnecting #2425

9names opened this issue May 4, 2024 · 2 comments · Fixed by #2466
Assignees
Labels
bug Something isn't working

Comments

@9names
Copy link
Contributor

9names commented May 4, 2024

Describe the bug
With probe-rs 0.23, pressing CTRL+C while running probe-rs run leaves RTT in non-blocking mode allowing the firmware to continue running indefinitely. This is (I think) the behaviour that we want.

With the current master (rev cf6ae5e) it does not, which means that when the RTT buffer eventually fills up the running firmware hangs.

To Reproduce
Install probe-rs cli from git.
Add defmt/rtt to your crate.
Log inside of a loop with an LED blink so that progress is observable without RTT
Run with probe-rs run from git
Observe that the program never locks up.
Press CTRL+C to disconnect debugger.
Wait for firmware to lock up

Expected behavior
RTT would switch to non-blocking and firmware would never lock up

@9names 9names added the bug Something isn't working label May 4, 2024
@bugadani
Copy link
Contributor

bugadani commented May 4, 2024

With probe-rs 0.23, pressing CTRL+C while running probe-rs run leaves RTT in non-blocking mode allowing the firmware to continue running indefinitely. This is (I think) the behaviour that we want.

Well, 0.23 didn't transition to blocking mode, so sort-of-maybe-not-exacly. Not transitioning back, however, is a mistake and thanks for noticing it.

@bugadani
Copy link
Contributor

Hmm I can't find where 0.23 changes channel mode, except in the dap server. Either way, this should be fixed by #2466 if I managed to find all points where we need to restore the flag :) 🤞

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants