You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been working on getting a simple USBD CDC device going on ch32v203. The existing driver (based on stm32) is mostly working, but there are a few deficiencies that I have discovered:
The driver does not enable its interrupt, this is a simple patch (or can be done in the application code via the PAC, but I don't think that is the idiom)
diff --git a/src/usbd.rs b/src/usbd.rs
index 55cdf97..aa26946 100644
--- a/src/usbd.rs+++ b/src/usbd.rs@@ -417,6 +417,11 @@ impl<'d, T: Instance> driver::Driver<'d> for Driver<'d, T> {
w.set_ctrm(true);
});
+ unsafe {+ use interrupt::typelevel::Interrupt;+ T::Interrupt::enable()+ };+
crate::println!("enabled");
let mut ep_types = [EpType::BULK; EP_COUNT - 1];
Wake from sleep does not work properly; this might also just require twiddling some bits, but I couldn't figure it out, manually setting up the USB wake event in EXTI didn't seem to help. Using embassy-executor feature arch-spin instead of arch-riscv32 works.
The SDI printlns throughout the driver cause frequent enumeration failure when a probe is connected and hang completely when one is not.
With these changes I was able to port with very few changes the stm32u0 usb_serial example, and it works.
It is unfortunate that the USBD is connected to a type-A port on the ch32v203 eval board.
The text was updated successfully, but these errors were encountered:
Unsure if this is related, but I'm getting a system hang on my CH32v203 whenever I initialize the USBD driver. I'm not sure if it has to do with interrupts not being enabled, but I've used SDI printing to pinpoint that the system stops at driver initialization. I'll try your interrupts patch and see if that fixes anything.
I can confirm that the failure of driver initialization was due to the lack of interrupts being enabled. Your fix worked perfectly. I'm getting new errors now where my device is unable to successfully set address and therefore is unable to communicate data over USB on both a Windows and Linux machine. However, I've found that this can be solved by a restart and then providing any signal to SWCLK, which suddenly enables USB. No idea why this works, but I'll keep testing.
I've been working on getting a simple USBD CDC device going on ch32v203. The existing driver (based on stm32) is mostly working, but there are a few deficiencies that I have discovered:
embassy-executor
featurearch-spin
instead ofarch-riscv32
works.With these changes I was able to port with very few changes the stm32u0 usb_serial example, and it works.
It is unfortunate that the USBD is connected to a type-A port on the ch32v203 eval board.
The text was updated successfully, but these errors were encountered: