-
Notifications
You must be signed in to change notification settings - Fork 726
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
USB ID 4000 on STM32H7R/S? #3289
Comments
yes, please send a PR! treating v4 the same as v2/v3 should be OK. Checking the core version is mostly used to workaround weird quirks in v1, if you tried that and it works then it probably means there's no quirks we should care about in v4. |
Turns out this was not working as I thought -- while it compiles, runs, and prints a lot of very beautiful INFOs, the usb FS-enabled pins don't actually exist on my board. Whoops. It compiles just fine if I switch it over to the HS pins (which I've confirmed are actually hooked up to the USB port this time, lol) but I'm getting a runtime panic that is completely stumping me:
I don't see usb as a field in rcc or mux. Any idea how I can set up that clock? I see usb in the rcc clocks module but no idea how to get it into the config. Also, I see there's only a new_fs function under Driver::, not a new_hs. I'm assuming that's fine, as a HS interface can run at FS speeds, unless I'm misunderstanding something? I don't need full HS data rates out of this thing, FS would be fine. Here's the rest of my code for context, which I'm running from inside examples/stm32h7rs/src/bin: `#![no_std] use defmt::{panic, *}; bind_interrupts!(struct Irqs { #[embassy_executor::main]
} struct Disconnected {} impl From for Disconnected { async fn echo<'d, T: Instance + 'd>(class: &mut CdcAcmClass<'d, Driver<'d, T>>) -> Result<(), Disconnected> { |
gonna try adding this bad boy to the config when i get back to the lab tomorrow
if it doesn't work i'm getting a consolation shawarma if it works i'm getting a celebration shawarma |
consolation shawarma it is, still broken with the same runtime error:
Any direction from anybody would be appreciated! |
Hey, I'm trying to get USB device mode working on a Nucleo-H7S3 as well. The problem might be the missing embassy/embassy-stm32/src/rcc/h.rs Line 701 in 1cf7789
I've set this to 48MHz (
Ultimately this should probably be integrated in the RCC and USB I've also adapted your clock configuration like this to configure the HSE:
By default, the USB PHY Clock Mux (which I didn't find represented anywhere in the I've also set the With these changes, this is the output I'm getting with your code:
During that first interrupt, the Here I am stuck as well though, as there are no further interrupts being generated and the board still does not enumerate. |
I've tried comparing the register state of the OTG_HS peripheral subsequent to calling the setup code (but before enumeration) both with Embassy and a working example from the Cube MCU package. I'm attaching the register dumps in case someone else also wants to take a look: So far I didn't get USB to work, but I've noticed that there seem to be some register definitions missing from I'm not sure how much of an issue this is though. If this was an actual problem, the OTG_HS peripheral shouldn't work on the U5 series either, as that has the same register definitions (cp. RM0456 sec. 73.14.18). Edit: Apparently someone else has already encountered this issue as well: embassy-rs/stm32-data#519 |
Howdy folks, hoping someone can point me in the right direction re: USB core IDs.
I spent the morning fiddling with the STM32H7 usb_serial example to get it to run on my STM32H7R/S board (this relatively new nucleo with a STM32H7S3L8H MCU), as there isn't a USB example for the R/S boards yet.
Changing some of the prescaler values in the initial config and pin #s got it to compile, but it would panic at runtime with this message:
I added 0x0000_4000 to the core_id match statement in the relevant file here, and just gave it the same config as the 200x and 300x ids. That seems to run the example just fine without any panic.
Would it be appropriate to submit a PR adding my example and appending 0x_4000 to that match statement with a v2_v3 config? Or are there additional considerations for core ID config beyond "this basic example works" that need to be addressed before adding support for a 4000 usb ID?
The text was updated successfully, but these errors were encountered: