JTAG upload fails

[DurandA]

Using either sipeed-rv-debugger or jlink (J-Link EDU Mini in my case) as upload_protocol, it fails with the following log on a Sipeed Longan Nano:

Open On-Chip Debugger 0.10.0+dev-00911-gcfbca74bd (2019-09-12-09:31)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Warn : Transport "jtag" was already selected
jtag
adapter speed: 1000 kHz

Info : clock speed 1000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)
Warn : JTAG tap: riscv.cpu       UNEXPECTED: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)
Error: JTAG tap: riscv.cpu  expected 1 of 1: 0x1e200a6d (mfg: 0x536 (Nuclei System Technology Co.,Ltd.), part: 0xe200, ver: 0x1)
Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing)), part: 0x9000, ver: 0x7)
Error: Trying to use configured scan chain anyway...
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 5 -expected-id 0x790007a3"
Warn : Bypassing JTAG setup events due to errors
Info : datacount=4 progbufsize=2
Info : Exposing additional CSR 3040
Info : Exposing additional CSR 3041
Info : Exposing additional CSR 3042
Info : Exposing additional CSR 3043
Info : Exposing additional CSR 3044
Info : Exposing additional CSR 3045
Info : Exposing additional CSR 3046
Info : Exposing additional CSR 3047
Info : Exposing additional CSR 3048
Info : Exposing additional CSR 3049
Info : Exposing additional CSR 3050
Info : Exposing additional CSR 3051
Info : Exposing additional CSR 3052
Info : Exposing additional CSR 3053
Info : Exposing additional CSR 3054
Info : Exposing additional CSR 3055
Info : Exposing additional CSR 3056
Info : Exposing additional CSR 3057
Info : Exposing additional CSR 3058
Info : Exposing additional CSR 3059
Info : Exposing additional CSR 3060
Info : Exposing additional CSR 3061
Info : Exposing additional CSR 3062
Info : Exposing additional CSR 3063
Info : Exposing additional CSR 3064
Info : Exposing additional CSR 3065
Info : Exposing additional CSR 3066
Info : Exposing additional CSR 3067
Info : Exposing additional CSR 3068
Info : Exposing additional CSR 3069
Info : Exposing additional CSR 3070
Info : Exposing additional CSR 3071
Info : Examined RISC-V core; found 1 harts
Info :  hart 0: XLEN=32, misa=0x40901105
Info : Listening on port 3333 for gdb connections
Info : device id = 0x19060410
Info : flash_size_in_kb = 0x00000080
Info : flash size = 128kbytes
Info : JTAG tap: riscv.cpu tap/device found: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)
Warn : JTAG tap: riscv.cpu       UNEXPECTED: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)
Error: JTAG tap: riscv.cpu  expected 1 of 1: 0x1e200a6d (mfg: 0x536 (Nuclei System Technology Co.,Ltd.), part: 0xe200, ver: 0x1)
Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing)), part: 0x9000, ver: 0x7)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
Info : Hart 0 unexpectedly reset!

*** [upload] Error 1

I tried both with RST pin connected or disconnected and it still fails the same way.

[DurandA]

@btx000 It works with latest OpenOCD from Nuclei (for me nuclei-openocd-0.10.0-13-linux-x64) from nucleisys.com.

Using the sipeed-rv-debugger there are a few Error: Can't run cJTAG reset escape sequences: TCK signal is not defined but at least the firmware was successfully uploaded. I guess this is due to incomplete sipeed-rv-debugger.cfg as it lacks a ftdi_layout_signal TCK line.

Could you repackage tool-openocd-gd32v to use OpenOCD from Nuclei?

[charlespax]

This happens to me too. Any work around by editing a file?

[JBKingdon]

@DurandA Many thanks for the link to Nuclei, that got uploading working for me. Finally no more fiddling with the boot/reset buttons!

I'm still not having any luck with debugging though, has anyone managed to get that working with the sipeed-rv-debugger and a longan nano?

[CharlesScoville]

~1.5 years latter and this still seems to be a problem. At least, it is for me on Ubuntu 18.04 LTS.

If this isn't going to be fixed in the official release for my OS, It would be really awesome if someone could take five to expand on @DurandA comment in a way that simply explains what a manual workaround one can incorporate into their own local system would look like. I'm not looking for a step by step, just more elaboration. "Works with", and "using", and "repackage" are all well and good, but it's also kinda vague, I'm needing more concrete specifics.

I'm expecting I can more or less just copy/paste some part from the updated Nuclei tool chain into PlatformIO's gd32v tool chain directory. Or similarly modify a file in the same location. However, it's unclear specifically which and where to do that from @DurandA's comment. I tried replacing the openocd executable, but that didn't do much. I've also tried poking around in PlatformIO's directories looking for sipeed-rv-debugger.cfg, but I can't find anything like that. And, even if I did, I'm not sure what I would have to do with it.

As of now, I'm running debug in PlatformIO via Atom to upload the firmware, then just killing the debugger session, and reset/power cycling the board. Aside from being tedious, and leaving debug symbols intact in my final firmware, it's also starting to take a toll on the reset button and my USB ports.

@JBKingdon

I'm still not having any luck with debugging though, has anyone managed to get that working with the sipeed-rv-debugger and a longan nano?

I'm currently able to do this, including all the nice debugging features like single stepping and what have you. As of July 2021 it just worked out-of-the-box, so I am of little help tracking down why it works.

[JBKingdon]

Oh wow, I'd completely forgotten about this. I went back to uploading via usb at some point (complete with incredibly annoying boot/reset dance) and completely neglected the debugger. Thanks for the pointer that the debugger is working now, I'll have to give it another go at some point.

[CharlesScoville]

Thanks for the pointer that the debugger is working now.

Yeah, no problem. Hopefully I get similar treatment from someone else.

Do note that I'm using Atom as my IDE, not the (sadly) more common VScode. My jtag debugger came from DigiKey, and looks suspiciously a lot like THIS. Debug is just the bug icon/button on the left, and I'm sure is very similar to what you find using VScode.

If that doesn't work, one CAN launch the modified openocd debugger totally manually via the command line, then attach that to the longan nano, but it's all very tedious, cryptic, and complex. I've done this once or twice just to see what CLI debugging would be like and -let me just say- I'm not at all about it. Even so, it's worth looking into as a troubleshooting step toward getting the GUI/IDE version of debugging to work.

[elfmimi]

@CharlesScoville put this gd32vf103.cfg as ~/.platformio/packages/tool-openocd-gd32v/share/openocd/scripts/target/gd32vf103.cfg .
It should just work.

[CharlesScoville]

@elfmimi
Oh, THAT'S where those files are. Well what the hell, I was looking for those and my search strings didn't find any of them.
...
OK, so, I just tried it.
For me, upload command is still not working as I would expect. Code still gets uploaded to flash, just still says there is an error with Info : Hart 0 unexpectedly reset!

In any case, ~domo

[elfmimi]

I guess I gotta provide some lengthy explanation.

At the time when GD32VF103 was being designed, reset was optional and not mandatory.
ndmreset (then) "This bit must not reset the Debug Module registers. What it does reset is platform-specific (it may reset nothing)"
ndmreset (now) "The signal should reset every part of the system, including every hart, except for the DM and any logic required to access the DM."

So, I guess, the designers decided to go with chip level reset without implementing ndmreset.
Whenever chip level reset is triggered, openocd prior to 0.11.0 complains about it.
That is the message you are seeing. > Info : Hart 0 unexpectedly reset!
openocd 0.11.0 knows about this situation and properly handles expected-unexpected-reset .

That means that it's okay to ignore those messages until Sipeed or anyone updates tool-openocd-gd32v package.

Modified version of gd32vf103.cfg of mine avoid chip level reset by emulating it and affording smooth debugging experience. However it cannot prohibit reset completely.
Following is the script code causing the reset after 'upload' .

platform-gd32v/builder/main.py

Line 186 in b32d988

"-c", "flash protect 0 0 last off; program {$SOURCE} verify; mww 0xe004200c 0x4b5a6978; mww 0xe0042008 0x01; resume; exit 0;"

mww 0xe004200c 0x4b5a6978; mww 0xe0042008 0x01;

You can replace this command with "reset;", along with my gd32vf103.cfg installed, if you really have to suppress that message after 'upload'.
the file is at : ~/.platformio/platforms/gd32v/builder/main.py

Or you can do the same thing within platformio.ini . but that is itself a complication so I'll save it for another day...