Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

USBD peripheral driver #79

Open
ktims opened this issue Jan 4, 2025 · 2 comments
Open

USBD peripheral driver #79

ktims opened this issue Jan 4, 2025 · 2 comments

Comments

@ktims
Copy link

ktims commented Jan 4, 2025

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.

@EK47
Copy link

EK47 commented Jan 20, 2025

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.

@EK47
Copy link

EK47 commented Jan 20, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants