Fails to flash using a GD-Link, a CMSIS-DAP debugger

[luojia65]

Describe the bug I tried to flash with a GD-Link debugger (CMSIS-DAP) connected, but error occurred.

To Reproduce Steps to reproduce the behavior:

1. Connect GD32VF103C-START board (with GD-Link) to the computer
2. Clone https://github.com/gd32v-rust/gd32vf103-hal
3. Execute cargo flash --example vf103c-start-blinky

Expected behavior The program should be flashed and the LED light blinks.

Stacktrace No stacktrace available

Desktop (please complete the following information):

• macOS Catalina 10.15.3

Additional context RUST_LOG=debug report:

Full RUST_LOG=trace report: https://paste.ubuntu.com/p/V5ygXJSqTz/

[Tiwalun]

The GD32VF103 is a RISC-V based chip, not an ARM chip, so we need to use JTAG for the connection.

[Yatekii]

Is this still an issue or could you fix this by using JTag as a protocol @luojia65 :)

[Tiwalun]

This is not implemented yet, we don't support raw JTAG for RISC-V using CMSIS-DAP.

[Yatekii]

Oh I am sorry, I completely forgot that JTag is not supported on CMSIS-DAP yet.

[elfmimi]

Is this issue solved? What I want to say here is, ... Why not open another issue to track support for GD32V ?

[Yatekii]

Thew problem here is that JTag is not implemented for CMSIS-DAP. If you want to put in the effort, please feel free to do that, I would gladly accept a PR. But it's so rarely used I don't see fit to put my time into it :)

[elfmimi]

Thanks for your reply. If no one is working on it, then I'll happily do it. I can't estimate how long it will take though. I'll get back here when I get something ready to show you.

[Yatekii]

@elfmimi what is the progress on this? :) I think @Disasm expressed interest in this too. I'll go ahead and mark this as an oxidize impl days issue. Maybe you folks make sure to coordinate :)

[elfmimi]

Hi! Not much progress. I was playing around with GD32V bootloader. Here is my progress on that side, if you are interested. https://github.com/riscv-mcu/gd32-dfu-utils/issues/5

As for probe-rs, I could proceed to the point ram_download example completes successfully. The difficult part is that, I mentioned this before, that GD32V has two entities in its jtag chain. So it is required to come up with acceptable modification to the existing framework which I suppose unlikely to end up small. I'm kept back here.

If Disasm-san or anyone is to get this done, I won't be pissed at all. No worry there.

[Yatekii]

@Disasm @elfmimi is this covered with the work done on FTDI? Or is there any other movement here? :)

[Disasm]

To support GD32V flashing we need three things:

• JTAG support for CMSIS-DAP. This one needs (preferably common for different probe types) a JTAG machinery that exists only for FTDI right now. Unfortunately, I still didn't find time to implement this.
• GD32V debug support. I checked GD32V debugging through FTDI and it didn't work well, apparently due to the GD32V<->FE310 debug module differences.
• GD32V flash algorithm

[Tiwalun]

@Disasm Could you try debugging the GD32V again? I recently fixed a small issue (see #423), and it should work better now.

[Disasm]

@Tiwalun I tried running cli with cargo run --features ftdi debug --chip riscv, but no success: https://pastebin.com/90bYeuQq This Target supports 0 breakpoints looks suspicious, because I believe this chip does support breakpoints.

[bugadani]

GD32Vxxx-START boards unfortunately seem to be impossible to source :(