PORTC on CH32V003A4M6?

[xsrf]

Hey, the CH32V003A4M6 doesn't have the GPIOs exposed that are used by default. I tried to use PORTC with PC1, PC2 and PC4 instead. Here is what I changed to try the bootloader:

usb_config.h:

#define USB_DM 1
#define USB_DP 2
#define USB_DPU 4
#define USB_PORT GPIOC

bootloader.c:

    // GPIO D3 for input pin change.
    USB_PORT->CFGLR =                                                                          // GPIOD -> USB_PORT
        (GPIO_CNF_IN_PUPD)<<(4*1) |  // Keep SWIO enabled.
        (GPIO_Speed_In | GPIO_CNF_IN_PUPD)<<(4*USB_DM) |  //PD3 = GPIOD IN
        (GPIO_Speed_In | GPIO_CNF_IN_PUPD)<<(4*USB_DP) |  //PD4 = GPIOD IN
        (GPIO_Speed_50MHz | GPIO_CNF_OUT_PP)<<(4*USB_DPU);

    // Configure the IO as an interrupt.
    AFIO->EXTICR = 2<<(USB_DP*2); //PORTD.3 (3 out front says PORTD, 3 in back says 3)         // 3 -> 2 (port-id?)
    EXTI->INTENR = 1<<USB_DP; // Enable EXT3
    EXTI->FTENR = 1<<USB_DP;  // Rising edge trigger

    // This drive GPIO5 high, which will tell the host that we are going on-bus.
    USB_PORT->BSHR = 1<<USB_DPU;                                                               // GPIOD -> USB_PORT

    // enable interrupt
    NVIC_EnableIRQ( EXTI7_0_IRQn );

The DPU is handled correctly (High for few secs), but I think the interrupt is not triggered. I see signals on DP/DM but I think they are just coming from the host. They don't change when I disconnect DP/DM from the MCU.

[xsrf]

getting closer

rv003usb.h

#define USB_GPIO_BASE GPIOC_BASE         // GPIOD_BASE -> GPIOC_BASE

Now windows reports Invalid Configuration Descriptor instead of Device Descriptor Request Failed.

[xsrf]

So, I looked at the USB communication with my Logic analyzer. It looks like all packets coming from the chip don't start with a proper SYNC. It always reads 0x02 or 0x03 instead of 0x01. So I actually think the first bit of the SYNC is missing 🤔

[cnlohr]

that is very interesting. I am not sure why that would be. I wonder if we don't actually support both ways for the DPU first. @duk-37 do you have any feedback on this?

[duk-37]

that is very interesting. I am not sure why that would be. I wonder if we don't actually support both ways for the DPU first. @duk-37 do you have any feedback on this?

I can try to replicate this on my end but this does seem extremely weird. An immediate first thought might be that these pins have some other peripheral (e.g. MC0) attached to them and that that's causing weirdness, but I can't say for sure.

Windows does work by default, though -- or at least it did a few weeks ago.

[xsrf]

I may try again with one of these boards https://www.aliexpress.com/item/1005005338043150.html and the default pins on PORTD. But last time I tried I got nothing. DPU works and pulls D- high for few seconds, but there is no reply to the host packets.

[xsrf]

Okay, I used one of these boards with the default bootloader again. Got nothing. I swapped D+/D- (DP now on D3, DM on D4) and now I get communication. Windows reports Invalid Configuration Descriptor but the logic analyzer shows me at least a valid DATA0 Packet from the device with idVendor and idProduct. Edit: Attached capture portd_datapins_swapped.zip

[xsrf]

I get the same result when I use the code adapted for PORTC on that board / CH32V003F4U6 (QFN). I need to swap D+/D- with respect to the code to get communication and Windows still reports Invalid Configuration Descriptor portc_datapins_swapped.zip

[xsrf]

Well, I now get the same result also on the CH32V003A4M6 with PORTC when I swap D+/D- (first sync bit missing makes perfectly sense when these are swapped ;) )

[xsrf]

So, I looked at the USB communication with my Logic analyzer. It looks like all packets coming from the chip don't start with a proper SYNC. It always reads 0x02 or 0x03 instead of 0x01. So I actually think the first bit of the SYNC is missing 🤔

I just started to rewatch your streams. @cnlohr you were actually getting the same errors with the first bit missing. You can actually see it driving the first bit in the analog view.

https://www.youtube.com/live/qbfnBAqssxI?si=7wZeabEFnZkGVa0C&t=10264

I guess this all boils down to #23 ? 🙈

[cnlohr]

Hmm, I'm also now having issues working on Port C (0 for DP, 1/2 for data).

Did you find any proper bugs?

Very cool you found it all though!

[arondr70]

I am using it normally by connecting USB to port-C. It has not been measured using a logic analyzer, and the MCU models and settings identified are as follows. I hope it's a reference.

• CH32V003J4M6 (SOP8)
• CH32V003F4U6 (QFN20)
• CH32V003F4P6 (TSSOP20) -- addded

define USB_DM 2 // USB D+ signal (PC2)

define USB_DP 1 // USB D- signal (PC1)

[cnlohr]

Whelp... I feel foolish. I never realized the DPU was misconfigured, to be required to be on PORTD. Still figuring out what's going on for me.

[cnlohr]

What other changes did you have to make to get your system enumerating?

[cnlohr]

Btw I fixed PORT C / other ports operation in a37efc3a6135e50a762dd7dd4b969f263f466059

[xsrf]

So... I now tried your CH32V003FUN board with the proper resistors installed

• 33R on PD4 to D-
• 33R on PD3 to D+
• 1K5 on PD4 to PD5

I also used your original bootloader code from last week with your default gpios. I won't get proper enumeration. Windows says Invalid Configuration Descriptor (I use nirsoft USBLogView btw.)

I now pulled your latest changes for rv003usb and ch32v003 fun and now the bootloader won't compile anymore:

../rv003usb/rv003usb.S: Assembler messages:
../rv003usb/rv003usb.S:54: Error: illegal operands `la a5,GPIO((GPIO_TypeDef*)(((0x40000000)+0x10000)+0x1400))_BASE'
../rv003usb/rv003usb.S:567: Error: illegal operands `la a5,GPIO((GPIO_TypeDef*)(((0x40000000)+0x10000)+0x1400))_BASE'
make: *** [../ch32v003fun/ch32v003fun/ch32v003fun.mk:27: bootloader.elf] Error 1

[xsrf]

Whelp... I feel foolish. I never realized the DPU was misconfigured, to be required to be on PORTD. Still figuring out what's going on for me.

btw. DPU is a really confusing name for the D- Pull-Up. On low speed USB, the D- signal needs a Pull-Up. On full speed USB, the D+ signal needs a Pull-Up.

[xsrf]

Here is the communication I get with your default bootloader on the ch32v003fun: ch32v003fun_bootloader_invalid_descriptor.zip

Looks exactly like what I already got and posted above for PORTC and PORD on my other two development boards 🤔

[xsrf]

Okay, so I booted a Linux Live-CD and there I see it enumerate properly as HID Device in dmesg. Both work, your CH32V003FUN and my CH32V003A4M6 on PORTC. So it's a windows issue all the time (since I got to Invalid Configuration Descriptor)? Here is the communication from the linux machine: ch32v003fun_bootloader_linux.zip

[xsrf]

So actually it also works on a different Windows 10 Dell Notebook, but not on my Windows 10 Surface Pro 7 (neither on the Surface itself, nor on the Dock). I'm confused now...

[xsrf]

Okay, so actually everything works except for the bootloader on my Surface Pro 7 and 6. I tried the bootloader on 3 other Windows PCs and it enumerates. I also tried the demo_composite_hid and it works with PORTC on CH32V003A4M6 an all devices, including both Surface.

So thx for a37efc3a6135e50a762dd7dd4b969f263f466059 and sorry for the confusion afterwards. Lets continue that in https://github.com/cnlohr/rv003usb/issues/24