Arduino Framework USB CDC/TinyUSB library include error

[Mapy542]

I apologize, this may not be an issue at all with your platform, but I have been unable to figure out how to use the USB CDC as a serial in the Arduino framework. I have tried to use both the openwch and ch32v build cores to no success. I have not been able to generate a COM device from the USB ports of a generic dev board. I can use the port to upload programs, though.

Best I can assume, this should work as a main.cpp file:

#include <Arduino.h>
#include <stdio.h>

void setup() { Serial.begin(9600); }

void loop() {
    Serial.println("Hello, World!");
    delay(1000);
}

ini File:

[env:genericCH32V307VCT6]
platform = ch32v
board = genericCH32V307VCT6
framework = arduino
upload_protocol = isp
board_build.core = openwch
board_upload.maximum_size = 294912
board_upload.maximum_ram_size = 32768

When I try openwch or ch32v build cores, nothing happens. When I add:

build_flags = 
	-D USE_TINYUSB

to openwch, I get

 8 | #include "Adafruit_USBD_CDC.h"
      |          ^~~~~~~~~~~~~~~~~~~~~
compilation terminated.
In file included from C:\Users\elimb\.platformio\packages\framework-arduino-openwch-ch32\cores\arduino\wiring.h:48,
                 from C:\Users\elimb\.platformio\packages\framework-arduino-openwch-ch32\cores\arduino\Arduino.h:36,
                 from C:\Users\elimb\.platformio\packages\framework-arduino-openwch-ch32\cores\arduino\HardwareSerial.cpp:27:
C:\Users\elimb\.platformio\packages\framework-arduino-openwch-ch32\cores\arduino\WSerial.h:8:10: fatal error: Adafruit_USBD_CDC.h: No such file or directory

I can see the TinyUSB library has been git sub-module included into the libraries folder of the framework. However, it doesn't seem to be found by the rest of the PIO platform.
Any help on getting USB communication set up via any means is appreciated. I do need to stick to C++, and ideally the Arduino framework.

[maxgerhardt]

We do have a TinyUSB + Arduino example for CH32V307 right in this platform at https://github.com/Community-PIO-CH32V/platform-ch32v/blob/develop/examples/tinyusb-arduino/platformio.ini. The main configuration macro for USB highspeed or fullspeed is

platform-ch32v/examples/tinyusb-arduino/platformio.ini

Lines 35 to 41 in 74097c0

	[env:ch32v307_evt_tinyusb_usbfs]
	board = ch32v307_evt
	build_flags = -DPIO_FRAMEWORK_ARDUINO_USBFS
	[env:ch32v307_evt_tinyusb_usbhs]
	board = ch32v307_evt
	build_flags = -DPIO_FRAMEWORK_ARDUINO_USBHS

Can you try that exact project?

[Mapy542]

I've uploaded that example project to no avail. All three 307 environment uploads do not work for me. It does not initialize a COM device on either of the two Type-C ports.

My dev board is possibly an odd flavor, not many are like it, and I can't find any documentation from the seller, even down to the built-in LED pinouts:
https://www.amazon.com/CH32V307VCT6-Development-Support-RT-Thread-Onboard/dp/B0DM9MD7JS?gQT=2

I was able to get the usb-cdc-wch32v307-none-os to create a COM device, but got no data from it.
Thanks for the support!

[maxgerhardt]

There is indeed a fault in maybe the PlatformIO builder script for the Arduino core. The clock source is not set correctly. With no further configuration, the chip stays at its HSI (8 MHz) configuration, which the USB startup code detects and rejects, as it needs at least 48 MHz from e.g. HSE or HSI (better HSE).

Now with the addition of -DSYSCLK_FREQ_144MHz_HSE=144000000 in the build_flags of the tinyusb-arduino example to nudge the system_ch32v30x.c to initialize the clock properly, I do get a USB device on one of the USB ports (the dev board has two!) called "TinyUSB Serial (Interface 0)". See e89c8c2.

Then, Windows driver weirdness kicks in and it loads a driver from WCH that's meant for the WCH-Link(E) instead of the serial port drivers.

So using Zadig, I have to revert that and load USBCDC drivers, which then gives me the actual COM port.

Opening that serial port with either the PlatformIO serial monitor (project tasks -> Monitor) or HTerm, there is data coming in, given that the virtual DTR line is asserted. The TinyUSB serial port will otherwise send no serial data. However, there seems to a bug with the buffer, in the sense that if the serial monitor is not opened immediately after the device boots, the device never sends data. So I had to press the reset button on the board and quickly reconnect the serial monitor, only then it would send data.

So we have at least two distinct bugs to work on here.

[maxgerhardt]

Another quirk is that the CH32V307 can be setup to multiple different ROM + RAM size configurations. But the Arduino core's linkerscript is hardcoded for the 64K RAM definition. This must be set in the chip via either the WCH-LinkUtility tool and a WCH-Link programmer or wchisp. Otherwise the firmware will not boot at all. Make sure to upload a "Blink LED" sketch to check that your chip is booting at all or needs that still ste.

[Mapy542]

Awesome! Including the -DSYSCLK_FREQ_144MHz_HSE=144000000 makes it work on both USB ports (depending on which env I upload).
It works out, I have a 64k variant from the factory, and don't have any of the weird wch-link drivers to mess with.

I can't replicate the serial buffer opening bug you mentioned. I have consitently had it open the serial monitor and send data, directly after upload, after reset, after replugging the usb, and having significant delay and instructions between the start of the script and the Serial.begin. Maybe an issue with the drivers you had to deal with?

"Make sure to upload a "Blink LED" sketch to check that your chip is booting at all or needs that still ste."
Funny thing, I can't seem to get, at least the built-in LED pins A15 and B4, to work on the openwch core. They work just fine in a simple Blink script on the ch32v core, but then I lose the USB CDC. I don't know how I missed this until now. Probably was testing on the other core for a while. My ini file matches the usb-arduino example. Any extra config I should look into? Otherwise, I can try to look into it or raise an issue on openwch's repo.

Thank you for the help!

[maxgerhardt]

Very interesting, maybe the buffer bug was just a randomness on my side. Will need to recheck.

The clock configuration was restructued in 58b2221, and is documented in https://pio-ch32v.readthedocs.io/en/latest/clock%20source%20configuration.html. As thus, afer a platform update, there is no need for the -DSYSCLK_FREQ_144MHz_HSE=144000000 anymore, just setup the clock source to hse+pll. The default frequency is already 144MHz (and HSI+PLL).

In total something like

[env:ch32v307_evt_tinyusb_usbfs]
platform = ch32v
board = ch32v307_evt
framework = arduino
board_build.core = openwch
monitor_speed = 115200
build_flags = -DPIO_FRAMEWORK_ARDUINO_USBFS
board_build.clock_source = hse+pll

The GPIO pins PA15 and PB4 are by default not accessible in the OpenWCH core's "digital pin" method, because it only deals with the "Arduino header" on a specific CH32V307 dev board. There is only digital pins 0 (D0) down to D21, as in

https://github.com/openwch/arduino_core_ch32/blob/d76716239cdf8a084a5045c3dfd3151b3f69eeec/variants/CH32V30x/CH32V307VCT6/variant_CH32V307VCT6.cpp#L20-L44

You can still write code to blink PA15 and PB4, but you'll have to use a slightly different method:

#include <Arduino.h>

/* PA_15 **not** PA15!!! Needs to use "fast" API that works on PinName type.*/
#define LED PA_15

void setup() {
  /* there is no pinModeFast() that natively takes PinName arg, so we have to call the underlying API */
  pin_function(LED, CH_PIN_DATA(CH_MODE_OUTPUT_50MHz, CH_CNF_OUTPUT_PP, 0, 0));
}

void loop() {
  digitalWriteFast(LED, HIGH);
  delay(1000);
  digitalWriteFast(LED, LOW);
  delay(1000);
}

please let me know if you get to blink PA15 and PB4 with that.

[Mapy542]

Thank you for the help with pin-interfacing. I figured it was something like that. Between now and my last reply, I checked all the pins and made a list of which ones work in the default digitalWrite. I figured it was a software setup. It's super helpful to be able to interface with all of them. Both A_15 and B_4 work, plus a few others I tested.

I checked, and the serial works well too, but only in hse+pll. I see there are other options, but only checked against hsi+pll. The internal version did not work for me. However, the default assignment and ini modification to hse both report the correct values during compilation

here. So, for me: hse works but hsi does not.

[maxgerhardt]

Do you use the high speed (HS) or full speed (FS) USB? USB is notorious for requiring a spot-on 48 MHz clock to work. The reference manual of the CH32V3x series mentions that for high speed USB, the clock source must be from HSE (the accurate crystal) instead of HSI (wobbly inaccurate RC-oscillator).

This post also says that.

Some microcontroller series are built though to be crystal-less USB 2.0 capable.