defmt::println over RTT not shown in terminal

[ghost]

defmt::println!("Hello, world!") does not produce output in the terminal window.

Code to repro.

hardware:

• nucleo-F767ZI powered over usb, nothing attached to pins.

software:

• probe-rs-debugger-0.3.3.vsix, probe-rs-debugger 0.12.0, probe-run 0.3.1

[noppej]

@DarrylN Hi, can you please add "rttEnabled": true to your launch.json and try again.

The default for this setting is false, even if you have defmt in your code.

[ghost]

Added "rttEnabled" = true, still no output.

note that 'cargo run' does show the output. 'cargo tree' output included below.

Running probe-run --chip STM32F767ZITx target/thumbv7em-none-eabihf/debug/hello
(HOST) INFO flashing program (7 pages / 7.00 KiB)
(HOST) INFO success!
────────────────────────────────────────────────────────────────────────────────
Hello, world!
└─ hello::__cortex_m_rt_main @ src/main.rs:8
────────────────────────────────────────────────────────────────────────────────
(HOST) INFO device halted without error
embsysdev@silvio:~/rust/embedded/hello-probe-rs$

$ cargo tree
hello v0.1.0 (/home/embsysdev/rust/embedded/hello-probe-rs)
├── cortex-m v0.7.4
│ ├── bare-metal v0.2.5
│ │ [build-dependencies]
│ │ └── rustc_version v0.2.3
│ │ └── semver v0.9.0
│ │ └── semver-parser v0.7.0
│ ├── bitfield v0.13.2
│ ├── embedded-hal v0.2.6
│ │ ├── nb v0.1.3
│ │ │ └── nb v1.0.0
│ │ └── void v1.0.2
│ └── volatile-register v0.2.1
│ └── vcell v0.1.3
├── cortex-m-rt v0.7.1
│ └── cortex-m-rt-macros v0.7.0 (proc-macro)
│ ├── proc-macro2 v1.0.36
│ │ └── unicode-xid v0.2.2
│ ├── quote v1.0.14
│ │ └── proc-macro2 v1.0.36 ()
│ └── syn v1.0.85
│ ├── proc-macro2 v1.0.36 ()
│ ├── quote v1.0.14 ()
│ └── unicode-xid v0.2.2
├── defmt v0.3.0
│ ├── bitflags v1.3.2
│ └── defmt-macros v0.3.1 (proc-macro)
│ ├── defmt-parser v0.3.0
│ ├── proc-macro-error v1.0.4
│ │ ├── proc-macro-error-attr v1.0.4 (proc-macro)
│ │ │ ├── proc-macro2 v1.0.36 ()
│ │ │ └── quote v1.0.14 ()
│ │ │ [build-dependencies]
│ │ │ └── version_check v0.9.4
│ │ ├── proc-macro2 v1.0.36 ()
│ │ ├── quote v1.0.14 ()
│ │ └── syn v1.0.85 ()
│ │ [build-dependencies]
│ │ └── version_check v0.9.4
│ ├── proc-macro2 v1.0.36 ()
│ ├── quote v1.0.14 ()
│ └── syn v1.0.85 ()
├── defmt-rtt v0.3.1
│ ├── cortex-m v0.7.4 ()
│ └── defmt v0.3.0 ()
├── panic-probe v0.3.0
│ ├── cortex-m v0.7.4 ()
│ └── defmt v0.3.0 ()
└── stm32f7xx-hal v0.6.0 (/home/embsysdev/rust/embedded/stm32f7xx-hal)
├── as-slice v0.2.1
│ └── stable_deref_trait v1.2.0
├── bare-metal v1.0.0
├── cast v0.3.0
├── cortex-m v0.7.4 ()
├── cortex-m-rt v0.7.1 ()
├── embedded-hal v0.2.6 ()
├── embedded-time v0.12.1
│ └── num v0.3.1
│ ├── num-complex v0.3.1
│ │ └── num-traits v0.2.14
│ │ [build-dependencies]
│ │ └── autocfg v1.0.1
│ ├── num-integer v0.1.44
│ │ └── num-traits v0.2.14 ()
│ │ [build-dependencies]
│ │ └── autocfg v1.0.1
│ ├── num-iter v0.1.42
│ │ ├── num-integer v0.1.44 ()
│ │ └── num-traits v0.2.14 ()
│ │ [build-dependencies]
│ │ └── autocfg v1.0.1
│ ├── num-rational v0.3.2
│ │ ├── num-integer v0.1.44 ()
│ │ └── num-traits v0.2.14 ()
│ │ [build-dependencies]
│ │ └── autocfg v1.0.1
│ └── num-traits v0.2.14 ()
├── micromath v2.0.0
├── nb v1.0.0
├── rand_core v0.6.3
├── stm32-fmc v0.2.4
│ └── embedded-hal v0.2.6 ()
├── stm32f7 v0.14.0
│ ├── bare-metal v1.0.0
│ ├── cortex-m v0.7.4 ()
│ ├── cortex-m-rt v0.7.1 ()
│ └── vcell v0.1.3
├── time v0.3.5
└── void v1.0.2
[dev-dependencies]
└── defmt-test v0.3.0
├── cortex-m v0.7.4 ()
├── cortex-m-rt v0.7.1 ()
├── defmt v0.3.0 ()
└── defmt-test-macros v0.3.0 (proc-macro)
├── proc-macro2 v1.0.36 ()
├── quote v1.0.14 ()
└── syn v1.0.85 (*)

[Yatekii]

This is most likely because you are using defmt 0.3 when probe-rs-debugger is using 0.2.

[noppej]

Actually, I suspect it has to do with the cortex_m::asm::bkpt(); that gets executed as part of the main loop.

Can you replace that with at cortex_m::asm::nop(); and see if that changes things? The debugger won't poll for RTT while the target is halted at a breakpoint.

[Yatekii]

Yep, that for sure is an issue too :)
But once that is resolved, defmt will for sure spew garbled up data because of the incompatible versions :)

[ghost]

changing from bkpt to nop() has no effect.

[ghost]

I reverted to defmt 0.2.0 and got this:

error[E0433]: failed to resolve: could not find println in defmt
--> src/main.rs:8:12
|
8 | defmt::println!("Hello, world!");
| ^^^^^^^ could not find println in defmt

I would like to use the probe-rs etc framework, but I'm not savvy enough in rust to resolve the dependencies. Is there a working example app with all the dependencies resolved?

[noppej]

I have a private one. Will send it in the morning. [Update] In testing my 'example app', I am now able to reproduce this ... I get no data back from defmt. Obviously something has changed since a previous release, so hopefully we can solve this soon. I am investigating and will get back to you.

[noppej]

Found it. There was a change that introduced new encoding and results in empty strings. I will implement a similar fix to what was done in cargo-embed and probe-run

[ghost]

Excellent! Will this be a point release on the vsix? Happy to verify when ready. I'm watching the repos.

[noppej]

Yes, and of the probe-rs-debugger. I will send you links when everything is ready for you to test.

[noppej]

@DarrylN Please can you test this with the combination of the attached VSIX file, as well as the special branch of probe-rs-debugger at

cargo install --git https://github.com/probe-rs/probe-rs probe-rs-debugger --branch noppej/issue894

probe-rs-debugger-0.3.4.vsix.zip

[noppej]

@DarrylN Also, as promised, you can look at the sample app stm32h745-defmt-rtt in this-repo for a recently tested example of using defmt on an STM32 board.

[ghost]

@noppej verified!

[ghost]

@noppej n.b. my Cargo.toml deps were the same as your example.

[ghost]

@Yatekii @noppej also, this works.

pub fn exit() -> ! {
    defmt::println!("exit");
    loop {
        cortex_m::asm::bkpt();
        //cortex_m::asm::nop();
    }
}

[edit] false. asm::nop is required to allow RTT polling to continue

[noppej]

Nice. I appreciate your patience and willingness to help verify. Thanks :)

[ghost]

@noppej Well...sad to report but now getting no output, same as before. Restarted vscode, no change. I noticed that the defmt terminal instance does not get created. probe-run still works correctly.

[noppej]

Did anything change since the last time it worked?

Have you tried disconnecting the board and reconnecting again?

[ghost]

@noppej
Yes, unplugged board from usb. Disabled the default rttChannelFormats in launch.json then reverted.

SWAG: maybe some VS internal flag is persisted with the session?

[edit] more info:
Output does not occur at all if asm::bkpt is used in the exit loop. asm::nop works, with issues as described below.
On initial launch (after restarting vscode), the defmt terminal instance is not shown at all.
Click restart on the debug toolbar, defmt terminal instance shows, but no output occurs until the exit loop is reached.

Expectation is that the defmt terminal should be created and updated when the output occurs. In other words, the first println output should be seen by the time the 2nd bp is reached.

Also getting this popup when a bp is set in lib.rs - path to src file is wrong:

[noppej]

@DarrylN Two quick comments

• The source file path is provided by the binary file (ELF format) and not much we can do about when it is wrong. In addition to this case, I've also seen it when the breakpoint happens in the RUST compiler builtins. Other debuggers will struggle with the same problem. The best we can do is to show assembly code for these cases. That is on our wish-list, and happy to accept PR's for that :)
• I will implement some additional error handling on the RTT to see if we can identify the root cause of why your RTT output gets lost. Watch this space for an update ...

[noppej]

Yes, please log it under probe-rs/probe-rs repo, and include the above. It should be easily fixable.