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

USB fails to enumerate when running CPU at 480MHz #503

Open
ryan-summers opened this issue Jul 26, 2024 · 6 comments
Open

USB fails to enumerate when running CPU at 480MHz #503

ryan-summers opened this issue Jul 26, 2024 · 6 comments

Comments

@ryan-summers
Copy link
Member

It was noted today that USB devices appear to not function if the CPU SYSCLK is set to 480MHz. However, if the CPU is dropped to 400MHz, USB works fine.

It's unknown if this is a HAL-related issue, USB-device issue, or silicon defect at this time.

I'm opening this just so we can get an initial read on things and get this documented somewhere.

@ryan-summers
Copy link
Member Author

@jamesmunns noted that he fixed an errata around this in embassy in embassy-rs/embassy#2823 that relates to USB being used in multiple ISR contexts

@olback
Copy link
Member

olback commented Jul 26, 2024

I think I ran in to this when I started my Arduino H7 project. I'm running at 480MHz but I'm specifying that USB should use the HSI48 clock source which seems to work fine.

https://github.com/olback/h7/blob/907250a846aacf50beab726f9387dd30a5ee3129/h7-cm7/src/main.rs#L123-L125

@ryan-summers
Copy link
Member Author

@olback That's interesting to me because we're running with very similar clock configurations: https://github.com/quartiq/stabilizer/blob/main/src/hardware/setup.rs#L292

Can you confirm that you're not seeing any USB-related issues with the cod eyou just referenced? I'm confused because yous aid you ran into this issue, but also that it seems to work fine now

@rockboynton
Copy link

I experienced this issue. The USB peripheral did work ~1 out of 5 flashing attempts. Also, I noticed my code specifically hang in the usb_device::device_builder::UsbDeviceBuilder::build() call

@jamesmunns
Copy link

Noting that ::build() is where the USB core is enabled via RCC, meaning it might actually be closer to embassy-rs/embassy#2677, where it takes a little bit before the RCC is actually active, which the software may be racing.

My suggestion is to insert a delay here: https://docs.rs/synopsys-usb-otg/latest/src/synopsys_usb_otg/bus.rs.html#366-517 after USB::enable().

@ryan-summers
Copy link
Member Author

ryan-summers commented Jul 29, 2024

On Matrix, it was noted that a user was able to resolve this by adding a ~1ms delay after the FDMOD register is configured. The datasheet specifies this needs to be at least 25ms:
image

This is likely a defect in synopsys-usb-otg.

Rock Boynton
it actually seems like I need to wait until after the // Configure USB PHY section to do the delay, otherwise I still see the issue. I can't just do the delay after the the FDMOD pin being set

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

4 participants