defmt log messages are unfindable in VSCode debugger - but are present on the console when running direct from cargo...

[anotherstevest2]

I'm working on getting someone else's "hello world" app running via embassy_executor on an STMF303 with probe_rs and with "cargo run --bin hello" it works as expected. But running within vscode and the probe_rs extension it all appears to work (I can even set breakpoints etc.) but I never see my defmt_rtt message (info!("Hello World!")). I've setup my launch.json per "No DEFMT output" from https://probe.rs/docs/knowledge-base/troubleshooting/ and still no joy. I can get lots of other debug output from other crates behind the scenes that I don't see when running directly from the console, but I can't see the output from my "Hello World" message. I've done a lot of playing around with the assorted logging options but I'm still, obviously, missing something. I'd appreciate ideas as to what I should try next. Thanks in advance!

[noppej]

There is obviously some weirdness/subtlety in the combination of your setup versus what probe-rs does. I use RTT every day, and it is quite reliable under VSCode.

Is there any chance you can share a minimum reproduce-able repo so I can debug?

[noppej]

@anotherstevest2 Did you forget to check in your code? I only see a README in that repo?

[anotherstevest2]

@noppej I pushed it to Master and, now a days, the default branch on GitHub is Main. I'm a slow learner. Checkout Master and you should see it.

[anotherstevest2]

@bugadani I tried adding "dataFormat": "Defmt" to the launch config (no apparent change) and then configuring channel 0 explicitly and no change with that either.

[noppej]

@anotherstevest2 I was able to reproduce your issue, and will work on it in the next couple of days. Watch this space for news :)

[anotherstevest2]

That's great. Thanks!

[noppej]

@bugadani In this repo, the launch.json has "rttEnable": true, instead of "rttEnabled": true

I seem to remember that you did some magic a while ago to make sure VSCode validates these entries. Do you remember what we need to do to flag this kind of typo?

[bugadani]

Playing around with this a bit, I think this is a vscode limitation. We could make probe-rs reject unknown properties, but I'm not sure if that would have side effects.

[noppej]

The only side-effects is that it would scream if users have unsupported (typo, made-up, or obsolete) options in their launch.json. I think that is preferable to silently ignoring it and leaving them wondering why said options don't have the expected effect.

[bugadani]

Great!. Additionally, I consider this firstly a vscode issue (either with nesting depth or objects-in-arrays), squigglies work the same way in the cortex-debug plugin (as in, they work in attach/launch level keys, but not in an objects-in-arrays keys). I'm not sure if this is intentional on their part.

[noppej]

@anotherstevest2 Can you please confirm that it works for you when you use "rttEnabled": true?

[anotherstevest2]

Yes! That fixed it. I appreciate your help finding what I should have been able to find myself . I apologize for my ineptitude... Thank you very much!

[noppej]

Not a problem at all. I'd like to keep this open so that we can figure out why the json validation didn't put ugly squiggly lines under it :)

[noppej]

Closing this issue, as any attempts to do additional configuration validation will be implemented on the probe-rs repository's dap-server component.