JTAG upload fails about platform-gd32v HOT 9 OPEN

@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?

from platform-gd32v.

@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

from platform-gd32v.

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' .

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...

from platform-gd32v.

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

from platform-gd32v.

@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?

from platform-gd32v.

~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.

from platform-gd32v.

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.

from platform-gd32v.

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.

from platform-gd32v.

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

from platform-gd32v.