USBD Status

[mattthebaker]

What work remains to get the usbd controller functioning?

I put together a quick attempt to get usb_serial working on ch32v203c8t6. It compiles and loads but the device doesn't seem to be initiating anything on the bus. Was wondering if its expected to be working (and I have an issue) or if there is more work required.

[romainreignier]

I think that the support is not there yet.
It is not listed in the status matrix of the Readme.

And from the last part of this comment, some work remains to be done.

[mattthebaker]

Great, thanks. I'm very interested in running USB on these chips for some projects, but not very familiar with ch32 or embassy so it would help greatly to get a comment on what might be missing. This branch is more or less a basic copy over from stm32 examples, which I attempted to run on ch32v203c8. I also have some ch32x035 dev boards.

https://github.com/mattthebaker/ch32-hal/tree/usb_serial Hopefully this helps to get usb bootstrapped.

AFAICT there was no activity on the bus, so it could be something as simple as peripheral power or pin mapping. I do have access to a USB bus analyzer but hadn't time to set it up. I haven't learned how to use the wch debugger yet. Likewise I have some stm32 dev boards to compare to if necessary if higher level issues show up.

[mattthebaker]

Have made some progress. The desktop isp tool defaults to turning on a watchdog and was causing issues.

I’ve got it as far as configuring, firing and handling reset interrupt, and acking the first setup packet from the host.

For some reason CTR interrupt doesn’t seem to fire for that SETUP and device hangs after entering WFI instruction.

[ExplodingWaffle]

don’t have time to make a pr right now and my own fork is a mess, but the issue you’re running into is that the ISRs from bind_interrupts have the wrong ABI so they remain active. add the qingke_rt::interrupt attribute in the macro. might also need feature
(naked_functions) in the examples

[mattthebaker]

Thanks very much, I'm getting a string of interrupts now with this adjustment. Expect that would have taken me quite awhile to figure out.

Slightly more bus interaction, onto the next but feels close.

[mattthebaker]

It all looks pretty close to functioning, but the USBD hardware doesn't seem to be writing anything into the dual port ram, haven't been able to figure out why yet.

[mattthebaker]

Overused the time I have to experiment for a bit, so just pushing it up.

By default PMAOVR bit seems to always be asserting when RXing the SETUP and just dropping the packet (doesn't get written to USBRAM). In some experiments where I was dumping the RAM to get more visibility some conditions seem to occur where the packet reception succeeds, so something about the state during/after reset when all of that overhead is there lets a packet get through.

Seems like there may be some quirk implementation quirk vs STM32F1 but not really sure yet.

If anyone knows if its possible to use defmt over SdiPrint it would help to access extra debugging info from embassy.

[Zoxc]

Have you tried to compare the code to https://github.com/cnlohr/ch32v003fun/tree/master/examples_x035/usbdevice ?

[mattthebaker]

I haven't tried anything else, used up all the time I had to mess with it, but the code is there for anyone that wants to continue.

The projects I was considering this for have switched to STM32C071 instead for a couple of reasons.

[mattthebaker]

Hmm, believe I got both changes into the build but didn't resolve the issue. Think it may be a different regression now though, as the USB doesn't do anything on the data lines any longer. Maybe something else changed with pin handling or the interrupt fix was clobbered, not really sure but no time to look more for now.

[Codetector1374]

Yeah thats sad. I dont have a device with usbd so I can’t really test / debug.

[mattthebaker]

I still think its probably 1 or 2 small things away from functioning, whatever is causing pins to not interact on USB -- don't have the debugger etc setup anymore, but I have USB analyzer -- is something new.

[Codetector1374]

Hahahah same i also got an usb analyzer to solve problems.

[andelf]

@Codetector1374 qingke-rt v0.4.0 is published. I've replaced naked_asm! with global_asm! for better version compatibility.

[Dummyc0m]

Hi @ExplodingWaffle,

I'm writing to discuss the plan for implementing the USB HS driver for CH32V30x. As I am wrapping up my work with the OTG/USBFS driver, I am looking to see what to work on next. Since I need to implement both device and host side driver for the FS and HS controller for some keyboard that I am working on, I am trying to see if I should tackle the FS host side or HS device side first.

I see you have made significant progress on implementing the USBHS driver, I do not want your work to go unnoticed / and write a driver from scratch. Do you still planning on finishing that driver up or have your interest shifted to other things already?

I can try to cherry pick your commit de8ac29b08e39bbaacc058c35c2180116e20790e and continue building / debugging the driver from there if you would like.

Thanks,
Yaotian/Codetector1374

[ExplodingWaffle]

Still working on it. actually I was waiting for you to finish working on otgfs so I could rebase onto that before PRing HS. will probably have the PR ready in 2-3 days actually. (funnily enough, I am also working on a keyboard firmware 😅)

[Codetector1374]

I see i already upstreamed the otgfs, and just started doing some refactoring of your code. I see you are doing FS only with the HS controller, is that the plan or do you plan to implement high speed mode as well? If you have other things to work on (looks like u r working on adc) feel free to leave the hs to us, we will tag you in the final commit to make sure you get the credit :)

[ExplodingWaffle]

alright, you can take care of usbhs :) not sure exactly what you meant by high speed mode? the speed_type bits i was only fiddling with for testing: high speed works fine also. the only real additional “feature” of usb hs on top of bigger numbers is high bandwidth endpoints, which should be possible since the MDATA and DATA2 PIDs are there in the controller, but not really something I need or am even sure fits into the model of embassy-usb… (i mean, right now embassy-usb doesn’t support switching configuration/descriptors etc based on the speed detected at reset, which is technically not needed: i mean, people have gotten HS working on some stm32s, but it does seem like a bit of a compatibility hole in case anyone finds a usb fs hub to plug your device into…)

[Codetector1374]

Yeah i meant the proper handling of DATA2/MDATA. I have not stared reading the spec about how those are used yet (haha). But i guess we will see what we can do in-terms of compatibility.