I recently purchased an RISC-V development board called the Longan Nano, which is based on the GD32vf103C family from GigaDevices. RISC-V is an open source ISA which seems to be getting some traction. Cheap dev boards are becoming available. There is apparently Arduino support, but I couldn’t get it to work properly in the arduino IDE. When installing the board support, there was a java error that the compiler wasn’t available for my operating system. Glancing at the issues for Longduino, it looks like similar errors are common with no response from the author.

The good news is that if you are willing to try PlatfromIO, there is good support for the Longan Nano. As a grumpy old unix guy, I’m a fan of EMACS. The Arduino IDE, while it’s simple to get started with, fits like a shoe that’s too small. PlatformIO has EMACS integration, so I went about setting it up. The docs are pretty good, and soon I was able to happily compile RISC-V blink examples.

I looked into how to connect my PC to the Longan Nano, and that’s where the trouble began. The simplest ting to try is the dfu upload_protocol and plug in the usb cable! In order to initiate the upload, you need to hold down the boot and reset buttons, then release reset, then release boot. That puts the device in dfu mode. I was mostly able to upload with dfu, but there isn’t a way to debug, and I was getting inconsistent upload results.

Looking at the supported upload methods, I see that I don’t own any of those devices, but I do own an ft2232h minimodule (or the equivalent). I was able to get the minimodule working by adding it to platforms/gd32v/platform.py. Below is the diff:

~/.platformio $ diff -u platforms/gd32v/platform.py.dist platforms/gd32v/platform.py
--- platforms/gd32v/platform.py.dist	2020-05-16 19:09:45.477399402 -0400
+++ platforms/gd32v/platform.py	2020-05-16 15:51:29.865143998 -0400
@@ -30,6 +30,7 @@
+            "minimodule",
@@ -80,7 +81,7 @@
                 "-f", "target/gd32vf103.cfg"
-            if link in ["um232h"]:
+            if link in ["um232h", "minimodule"]:
                 server_args.append("adapter_khz 8000")
                 server_args.append("adapter_khz 1000")

Once this is done, I can add (or change) a couple of lines in my platform.ini:

debug_tool = minimodule
upload_protocol = minimodule

and make some connections to my Longan Nano:

ft2232h Longan Nano
3.3v 3.3v

With all of this setup, I can now run my upload with platformio run --target upload. I get a funny notice at the end of the upload:

** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
Info : Hart 0 unexpectedly reset!

*** [upload] Error 1
================================================== [FAILED] Took 1.43 seconds ==================================================

Pushing the reset button doesn’t seem to start the program, but when I disconnect and connect the power, the led starts blinking.

One of the sharp edges that I tripped over was the fact that the RGB led is connected to the power rail instead of ground like it is on the Arduino. This means that setting the LED pin to LOW turns on the LED.

Now that I’ve done all this hacking about in platformio, it’s probably time to make up a couple of PR’s so that hopefully, other folks won’t need to do all of this discovery themselves.

Update 2020-05-19 I had forgotten about a problem I had when trying to upload through the JTAG interface. There was an error near the end of the upload:

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

This error doesn’t seem to prevent an upload. You can clean up the error by editing the file ~/.platformio/packages/tool-openocd-gd32v/share/openocd/scripts/target/gd32vf103.cfg and changing line 2 from:

jtag newtap $_CHIPNAME cpu -irlen 5 -expected-id 0x1e200a6d


jtag newtap $_CHIPNAME cpu -irlen 5 -expected-id 0x1000563d

Yet another PR for me to consider pursuing.