Correct Debug setup

[Usioumeo]

Hi, I'm developing a project and I would like to setup it "in a solid way".
I had wrote a library, and I'm writing the ch32 implementation (mainly for ch32v307 and ch32v305).
Inside the library for debugging purpose I used the defmt-or-log crate in order to debug with log with native tests, and with defmt (or nothing) while on a microcontroller.

Obviously I also needed to provide an rtt channel in order to communicate (used rtt-target), and while I upload the code with probe-rs I can see the output from the defmt macros. Also on vscode I can launch the debugger, stop and resume execution, inspect variables ecc.

This is a HUGE step forward from the sdi-print based debugging, but there is a small problem.

I have a very light task that gets awakened at around 40KHz, but when I upload the code with probe-rs (even if I did not print anything with defmt), it gets called almost half the times! But if i restart the program without probe-rs attached it works as intended, but when I attach it with probe-rs attach it starts immediately dropping events.

From what I read online the wlink probe should be fast enough, and in theory jtag shouldn't mess with the microcontroller too-much (it is the whole point right?).

So, I've seen that in the config.toml of the example there are commented lines for run the code with probe-rs so I suppose that someone tried before.
Am I doing something wrong? It's a bug in how probe-rs interacts with the probe (maybe too many polls each second)? Simply the probe is not intended to be used in time sensitive application (given that I don't think 40kHz is that much for a 144Mhz processor, and if there is no active communication I think the probe should read a couple of bytes at 10Hz).
Let me know what you think

[ExplodingWaffle]

as far as I can remember, these chips don’t support memory readout while they’re running: in other words, the only way RTT can “work” is for the debugger to constantly halt the chip.
To be honest I’m a little surprised this “worked” at all: it has been a while so I could be misremembering, but I swear the last time I tried this you wouldn’t get any RTT at all until explicitly halting the chip, so the buffer would fill up and it would be ~useless. I guess this new behaviour is an improvement?

But yeah, TLDR is that RTT cant work. Which is a real shame. The RISC-V debug spec does support memory readout, but it’s optional. wch pls fix

[Marcuss2]

In theory, you could set up to transmit defmt messages via the "sdiprint" functionality.

Albeit this would require support from probe-rs.

[Usioumeo]

After the previous message I give it a try to implement the logging process with the "sdiprint" functionality, and it actually worked.
I needed to implement a defmt::global_logger in order to explain how to send messages. Because the SDIPrint abstraction implements fmt::Write so it is not possible to send raw bytes (only chars/str). So I reimplemented a function to write raw data to SDI, and it actually started to send correctly packet data. In order to decode them on host side I use socat to read the serial and defmt-print to decode the packets. And it works with much less overhead!! (obviously if more than 7 Bytes are sent the function gets blocking).

If some maintainer thinks it is a good idea I could open a pull request with an additional implementation of io::Write for SDIPrint (so that it can be used in other ways without reimplementing it). Also with an additional new feature flag (+"defmt") it could be possible to enable the global_logger implementation. Let me know what you think.

Last thought said out loud. With probe-rs it is possible to "preverify" the flash before uploading the code, in this way it gets flashed (and also worn out the memory) only if the binary actually changed. Does wlink support/plan to support it? Because right now I have a custom run script that uploads the binary with probe-rs, then it enable the sdi-print functionality with wlink, and in the end uses socat and defmt-print to log to terminal. Let me know what you think