Hi,
Is their a way to use the USB port to change it to a serial port via a virtual serial port ?
It’s really nice to interact with the board without any USB-serial module (FTDI, CH340 etc.). On the host side you just need to have a virtual serial com port, included in all modern OS, Linux or even Windows.
I use it with STM32 for debug or interact on little projects, it’s really convenient.
I’ve only found an example with USBFS stuff, but nothing related to a serial port.
Cheers,
Phil
Hum, seems from this repo there is something interesting: https://github.com/riscv-mcu/GD32VF103_Firmware_Library/tree/master/Examples/USBFS/USB_Device/CDC_ACM
Now I need to figure out how to use this sample code.
Nice, what is the progress ?
Hi Zepan,
For the moment I’ve forget the idea of using the USB driver. Let me explain a little.
I’ve spent 4 or 5 days to try to compile this one. After having setup everything on Windows or Linux I always got this error:
_Other\usb-ser/src/cdc_acm_core.c:388: undefined reference to
usbd_ep_recev' c:/users/migou/.platformio/packages/toolchain-gd32v/bin/../lib/gcc/riscv-nuclei-elf/9.2.0/../../../../riscv-nuclei-elf/bin/ld.exe: .pio\build\sipeed-longan-nano\src\cdc_acm_core.o: in functioncdc_acm_data_send’:
c:_Other\usb-ser/src/cdc_acm_core.c:402: undefined reference tousbd_ep_send' c:/users/migou/.platformio/packages/toolchain-gd32v/bin/../lib/gcc/riscv-nuclei-elf/9.2.0/../../../../riscv-nuclei-elf/bin/ld.exe: .pio\build\sipeed-longan-nano\src\app.o: in functionmain’:
c:_Other\usb-ser/src/app.c:70: undefined reference to `usbd_init’
etc…
It means all the source code was OK, it failed during the link.
While searching the error I’ve notice that during the compilation stage it even forgot to generate the .o file for the USB driver, despite all the includes referencing the .h file of the driver.
I’ve spent time on tuning the lib discover in PlatformIO, but again no result (http://docs.platformio.org/en/latest/librarymanager/ldf.html).
I was thinking founding a bug in Platformio or in the framework, so I’ve load the source code of the target GD32V to check how a new target is added in Platformio.
And after reading and understanding the build process I went on the file “fimware_libray.py” and this awful piece of code:
> #
> # Target: Build Core Library
> #
>
> libs = [
> env.BuildLibrary(
> join("$BUILD_DIR", "standard_peripheral"),
> join(FRAMEWORK_DIR, "GD32VF103_standard_peripheral")),
>
> # env.BuildLibrary(
> # join("$BUILD_DIR", "usbfs_driver"),
> # join(FRAMEWORK_DIR, "GD32VF103_usbfs_driver")),
>
> env.BuildLibrary(
> join("$BUILD_DIR", "RISCV"),
> join(FRAMEWORK_DIR, "RISCV")),
>
> ]
>
> env.Prepend(LIBS=libs)
I was a little upset of this one 
It tells to the Platformio to NOT build the USB lib !!!
I’ve tried to uncomment it and it failed to compile. Then I understood why it was commented: nothing is building with this libs. And I didn’t found a tricks to achieve it by correcting the source code of the USB lib.
So I’ve drop it. And now I use the USART0, a shame regarding the ability of the module. But I need to achieve something with this board and not loose more time on a BETA framework (I know it’s a bad spirit of only complain, but I don’t have the knowledge in development to correct the driver, I’m not a developer).
So maybe on the next release of the framework or with the help of someone it could be usable. With the problem clearly spotted it’s now possible to go further.
Cheers,
Phil
Interesting finding Phil. The missing function usbd_init exists in the source code tree. Have a look here
So we need to understand why this file is not included in the build. I have no clue how this build system works unfortunately. But if I have time I will take a look at compiling the examples. Can you perhaps attach the log from your build?
Yes the function is in the source code, but have a look at the upper commented code I’ve spotted : it ask to ignore the compiling of the USB files.
So with this bug the SDK does not add all the USB functions to the lib & bin generated and it failed during the link stage. You have the error in the post upper.
As I said I’ve drop the idea for the moment to use the USB- port for other things than a power supply 
Cheers,
Phil
With some tweaks I was able to compile this example. It seems that the issue why USB library is commented out from the build is that there is no clear separation between library and application code currently. I had to move a lot of includes from other examples (e.g. HID) and add some more #defines before it compiled. I did not see by the way your error message. Unfortunately there are more issues:
drv_usb_core.c function usb_txfifo_writeuses _packed on a pointer*fifo = *((__packed uint32_t *)src_buf);__attribute__((packed)) instead and this does not work on a pointer cast. I defined __packed to empty and doubt that this works.In the end I uploaded the example firmware to the board and did not even get an event that an USB device was connected on the host PC Perhaps others have more luck.
So my initial think was the SDK is unfinished and it’s a loose of time to try to debug it. The 3 commented lines to NEVER compile this USB part of the SDK says a lot !
Thanks for having tryed, but we need to wait some news from China 
Just for others facing the compilation issue with gcc. I tried to add
build_flags =
-D__packed=__attribute__((packed))
This gives a syntax error, but the problem probably is that platformio passes the parentheses unescaped to the shell and this results in an error. I then tried to change this directly in the code:
*fifo = *((__attribute__((packed)) uint32_t *)src_buf);
and this gives only a warning:
drv_usb_core.c:251:9: warning: 'packed' attribute ignored for type 'uint32_t *' {aka 'long unsigned int *'} [-Wattributes]
So this should not have any effect and defining this to nothing should be fine:
build_flags =
-D__packed=
Be aware that this is a dangerous way! This only works if __packed is used nowhere else.
Nobody has a clue from china ? It would be great to be able to use the USB directly !
@mouseclicker was the most advanced on the subject. And it’s clearly not enough.
I think now it’s time to contact guys responsible for the SDK, or try to log bugs on the GitHub, because it’s visible and maybe it’ll force a little the dev team to have a look.
And don’t forget it’s a new chip, with possible unpatchable hardware bugs the seller will try to silence ;).
Hi Phil, Matoni,
I still not gave not up on this topic. Unfortunately I have broken my display and then it is even more difficult to get some logging information. Got a replacement now, just need time… I don’t think that this is a hardware issue. However the whole platform: SDK, Arduino layer, PlatformIO integration is not very mature. Documentation is sometimes poor, examples are only partially helpful. You don’t see any commits in the Github repos and there is never any comment on the issues from the vendor. The other question is how much you can expect from a $5 board (which in fact is more €10 board). I also have the impression that the community here is quite small. RiscV is still pretty new.
If it is helpful I can provide my example code on Github. Not working at all but if some other are curious to look into this just let me know. It also would be interesting to see if some of the other USB examples (e.g. HID) are working. If there is progress I will share.
Hmmm, GigaDevice, the factory who build the MCU is in the spirit of doing a STM32F1xx killer, pin to pin compatible, same memory segment, same flash & RAM size etc. It’s a HUGE market, so the 5$ are worth the effort. But after, I’m not really aware of who must release the SDK: the chip burner or the board builder ? What is seen as middle-ware and enough generic to be widely used?
Great, I’ll publish something later to add more weigh to the ticket 
About my project, it’s finish and I’ll have late interest on the board now, but I keep an eye on it.
My project was this: Write-up HERE
Something more related to security challenge for an event than something running every days.
Cheers,
Given this compatibility an idea came into my mind trying to compile and flash the STM32 firmware to this board and check if this works. But despite all the effort this is probably a stupid idea. Not sure if this contains assembly code and probably things like interrupt handling are still very different. Still wonder why they invented their own and didn’t port the one from STM. It seems that they didn’t try to achieve compatibilty on software level.
Bot now we are off-topic… sorry
I figured out why the sample does not work. There is a function usb_core_reset in the USB firmware part. The while loop waiting for the USB bus reset is waiting forever. I added this to the issue mentioned above. Now this is so close to the hardware that this likely won’t be resolved without help from sipeed. Let’s see what happens with the issue. Or does someone have an idea what might cause a USB reset to fail?
Any news for this problem ? Does somebody managed to use USB communication ?
I’ve managed to compile and run one of the USB CDC examples (slightly edited to show how it works better). Decided to circumvent the non-compiling driver by just dropping the files directly into the project. Except for a missing include it seems to compile fine and a flashed chip shows up as a proper serial port.
Link to repo -> [https://github.com/linusreM/GD32V-Virtual-COM-Port]
This could be cleaned up a lot, but shows something working at least.
Thank you for this solution, it works quite well.
There is a small issue, the iManufacturer, iProduct and iSerial strings are not shown:
boris@UbuntuMate:~$ lsusb -v -d 28e9:018a
Bus 003 Device 034: ID 28e9:018a
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x28e9
idProduct 0x018a
bcdDevice 1.00
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
It can be solved ba adding the -fshort-wchar build flag into platformio.ini:
[env:sipeed-longan-nano]
platform = gd32v@1.1.2
board = sipeed-longan-nano
framework = gd32vf103-sdk
upload_protocol = dfu
build_flags = -fshort-wchar
Now the correct strings are shown;
boris@UbuntuMate:~$ lsusb -v -d 28e9:018a
Bus 003 Device 048: ID 28e9:018a
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x28e9
idProduct 0x018a
bcdDevice 1.00
iManufacturer 1 GigaDevice
iProduct 2 GD32 USB CDC ACM in FS Mode
iSerial 3 GD32XXX-3.0.0-7z8x9yer