This repository has been archived by the owner on Aug 27, 2021. It is now read-only.
GD32F103C8 RTT initialization fails due to failing read of channel name from flash memory #30
Labels
bug
Something isn't working
Describe the bug
I have a small blinky program running on a GD32F103C8 microcontroller which uses defmt over RTT to print debug messages. I am using the STM32F1xx HAL because the controllers are somewhat compatible and there is no specific crate for the Gigadevices chip.
I am using
probe-run
to flash the binary and use it to print the log messages over RTT. When I try it on an STM32, it works as expected. The GD32 on the other hand gets flashed successfully and then the RTT initialization fails. The program runs fine.I tried a J-Link and an ST-Link v2 and both fail in a similar way:
J-Link:
ST-Link v2:
I started debugging this and this is the tracing output of
rtthost
using a J-Link before it fails:When I try it with an ST-Link, the trace becomes a bit more readable, but it is also operating on a much higher level when communicating with the debug subsystem:
Here command
[f2, 3e]
seems to repeatedly fail. 0xf2, 0x3e is a JTAG command namedJTAG_GETLASTRWSTATUS2
, so apparently some read or write is failing. After littering the code with debug logging, I managed to narrow down what is exactly happening here:It manages to find the RTT descriptors in SRAM after scanning for them linearly, it parses everything and then tries to read the channel name. In my case, the name is located in flash at address
0x0800168c
. This read fails on the GD32. Both the J-Link and the ST-Link fail to read the flash in the same way as far as I can tell from the tracing output. (I left out the sweeping part in the traces, it's just the failing read until it gives up and errors out)I then created a small test application using
probe-rs
which replicates reads from beginning of SRAM and flash using both theMemoryAP
directly, as well as using a session with the STM32F103 target selected. On both of these versions, the read from RAM always succeeds and the flash read always fails UNLESS the CPU core is halted. As soon as I halt the CPU core, the flash read succeeds all the time (when using theMemoryAP
it really fails with an error, when using theSession
it returns zeros).Example for the reads with the session:
After that I added the code to halt the CPU core for just the flash read to
probe-rs-rtt
and rebuiltprobe-run
using my patched version which magically started to work.The patch:
Now I don't know enough about the internals of the GD32 to exactly know what's going on or if there is another way to make it work by poking the right registers during startup, but something is definitely wonky here.
For a short time, because the naming scheme confused me, I used the
gd32f1x0-hal
crate which is the correct HAL for the F130 instead of the F103. When I used this and just had a tight loop with some prints going over RTT, it worked fine. It dawned on me that this is the wrong crate when I got hard faults for accessing the GPIO controller to make an LED blink. I don't know yet what the exact difference between the two crates is that makes RTT work or not.So if anybody has an idea what to try out to make this flash read work without halting the core, I would be happy to try it.
edit: I am not able to make RTT work again by using the wrong crate. I wanted to disassemble and diff the resulting binaries, but I seem to be unable to make it work again :-/
To Reproduce
Steps to reproduce the behavior:
probe-run
to flash and run your code, watch the RTT part failExpected behavior
RTT should work
The text was updated successfully, but these errors were encountered: