Strange RTT issues on ESP32C3 when using embassy

[dzamlo]

Strange RTT issues on ESP32C3 when using embassy

[MabezDev]

This is most likely a defmt issue because they construct the header in a way that allows the debugger to attach to it, but isn't fully initialized. It should be fixed there, rtt-target doesn't have this problem, but obviously doesn't support defmt.

[dzamlo]

I have the same issues with rtt-target: https://gitlab.com/dzamlo/minimal-example-rtt-issue/-/tree/rtt-target?ref_type=heads

[dzamlo]

I have the same issue with the rtt backend of esp-println

[dzamlo]

If I remove the .await, using hal::Delay to wait instead of Timer, but let everything else the same (still an async function, embassy still initialized), it seems to works as expected.

If I use .await for something else than a timer, like waiting for a falling edge on a gpio, I get the issues.

[dzamlo]

After further investigation, it is the call to core::arch::asm!("wfi"); that cause the issue, so nothing to do with async in itself. I've made a minimal reproduction: https://gitlab.com/dzamlo/minimal-example-rtt-issue/-/tree/wfi-example?ref_type=heads

I get the same issues with an esp32-c6.

[dzamlo]

I can reproduce the issue on a STM32L476 (on a nucleo board with a ST-LINK/V2-1): https://gitlab.com/dzamlo/minimal-example-rtt-issue-arm

In addition to RTT issues, I sometime cannot even flash the board and get one the following error messages:

Error: Connecting to the chip was unsuccessful.

Caused by:
    0: An error with the usage of the probe occurred
    1: An error specific to a probe type occurred
    2: Command failed with status SwdDpWait

Error: Connecting to the chip was unsuccessful.

Caused by:
    0: An ARM specific error occurred.
    1: The debug probe encountered an error.
    2: An error specific to a probe type occurred
    3: Command failed with status JtagNoDeviceConnected

The solution to recover is to connect BOOT0 to VCC and unplug, replug the board.

[Yatekii]

It is know that WFI can cause this dependent on what debug bits you set because the chips disable the debug unit. But we can become more resilient I guess.

Duplicate of #350.

[dzamlo]

Is there any way to detect this situation ? It would be very helpful to show a link to a page that explain the situtation in this case, instead of just having the logs not working.

[Yatekii]

It would be nice to at least display a hint I guess, but it's not easy to really know.