PlatformIO Community

Problems with debugging a Longan Nano with RV-Link

I have two Longan Nanos, and I’m using one as the RV-LINK debugger in PlatformIO with Visual Studio Code under Windows 10 to debug the other one.

This is working to some extent, but not as good as I would expect. For example when the program hits a breakpoint, the debugger stops in an assembler listing and not in the corresponding source file. Breakpoints set in Visual Studio Code by clicking into the source file don’t work. On the other hand if I set a breakpoint in the Visual Studio Code debug console directly via a gdb command then the break point has an effect.

This is my platformio.ini file:

[env:sipeed-longan-nano]
platform = gd32v
framework = gd32vf103-sdk
board = sipeed-longan-nano
monitor_speed = 115200
upload_protocol = rv-link
debug_tool = rv-link
build_type = debug
debug_port = COM5

Is something missing here to get source-level debugging to work?

This is shown in the debug console when starting a debugging session:

Processing sipeed-longan-nano (platform: gd32v; framework: gd32vf103-sdk; board: sipeed-longan-nano)
--------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/gd32v/sipeed-longan-nano.html
PLATFORM: GigaDevice GD32V 1.1.0 > Sipeed Longan Nano
HARDWARE: GD32VF103CBT6 108MHz, 32KB RAM, 128KB Flash
DEBUG: Current (rv-link) External (altera-usb-blaster, gd-link, jlink, rv-link, sipeed-rv-debugger, um232h)
PACKAGES:
 - framework-gd32vf103-sdk 1.0.0
 - toolchain-gd32v 9.2.0
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 0 compatible libraries
Scanning dependencies...
No dependencies
Building in debug mode
Checking size .pio\build\sipeed-longan-nano\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [=         ]   7.0% (used 2310 bytes from 32768 bytes)
Flash: [          ]   4.9% (used 6472 bytes from 131072 bytes)
========================= [SUCCESS] Took 0.94 seconds =========================
Reading symbols from e:\Users\stm\Documents\GitHub\longannano\���\longan-nano-blink\.pio\build\sipeed-longan-nano\firmware.elf...
undefinedC:\.platformio\packages\toolchain-gd32v\bin\riscv-nuclei-elf-gdb.exe: warning: Couldn't determine a path for the index cache directory.
PlatformIO Unified Debugger -> http://bit.ly/pio-debug
PlatformIO: debug_tool = rv-link
PlatformIO: Initializing remote target...
0x08000fba in __divdf3 (a=<optimized out>, b=<optimized out>) at ../../../../.././riscv-gcc/libgcc/soft-fp/divdf3.c:46
46	../../../../.././riscv-gcc/libgcc/soft-fp/divdf3.c: No such file or directory.
Temporary breakpoint 1 at 0x8000428: file src\main.c, line 71.
RV-LINK v0.2: Longan Nano, configed for GD32VF103 family.
Loading section .init, size 0x236 lma 0x8000000
Loading section .text, size 0x169e lma 0x8000240
Loading section .sdata2._global_impure_ptr, size 0x4 lma 0x80018e0
Loading section .data, size 0x70 lma 0x80018e4
Start address 0x800015c, load size 6472
Transfer rate: 11 KB/sec, 719 bytes/write.
:( unsupported monitor command!
PlatformIO: Initialization completed
PlatformIO: Resume the execution to `debug_init_break = tbreak main`
PlatformIO: More configuration options -> http://bit.ly/pio-debug
Note: automatically using hardware breakpoints for read-only addresses.

Temporary breakpoint 1, main () at src\main.c:71
71	    longan_led_init();

After more experiments I have found the reason for the problem: If any parent directory of the PlatformIO project directory contains a non-ASCII character, source-level debugging is broken. I updated the debug console logging output in my previous post as I had copied the wrong logging output.

In the logging output there are three “���” characters. In the file system the directory name is actually “äää” (three U+00E4 characters). After renaming the project’s parent directory to contain only ASCII characters source-level debugging via RV-LINK is working as expected for the same project.

The following issue on GitHub describes the problem already:

1 Like