Closed hacknus closed 1 year ago
usb-device doesn't use allocator, so the problem is located somewhere else.
Ok, I found out that with the debugger, it hangs in this line:
while read_reg!(otg_global, regs.global(), GRSTCTL, AHBIDL) == 0 {}
line 365 in .cargo/registry/src/github.com-1ecc6299db9ec823/synopsys-usb-otg-0.3.1/src/bus.rs
full output of the debugger:
synopsys_usb_otg::bus::{impl#2}::enable::{closure#0}<stm32f4xx_hal::otg_fs::USB> (cs=<optimized out>)
at /Users/linus/.cargo/registry/src/github.com-1ecc6299db9ec823/synopsys-usb-otg-0.3.1/src/bus.rs:365
365 while read_reg!(otg_global, regs.global(), GRSTCTL, AHBIDL) == 0 {}
(gdb)
halted: PC: 0x08002ace
halted: PC: 0x08002ac6
synopsys_usb_otg::ral::register::RWRegister<u32>::read<u32> (self=<optimized out>)
at /Users/linus/.cargo/registry/src/github.com-1ecc6299db9ec823/synopsys-usb-otg-0.3.1/src/ral/register.rs:23
23 unsafe { ::core::ptr::read_volatile(self.register.get()) }
(gdb) step
0x08002ac6 in core::ptr::read_volatile<u32> (src=<optimized out>) at /rustc/659e169d37990b9c730a59a96081f2ef7afbe8f1/library/core/src/ptr/mod.rs:1521
1521 /rustc/659e169d37990b9c730a59a96081f2ef7afbe8f1/library/core/src/ptr/mod.rs: No such file or directory.
(gdb) step
halted: PC: 0x08002aca
synopsys_usb_otg::bus::{impl#2}::enable::{closure#0}<stm32f4xx_hal::otg_fs::USB> (cs=<optimized out>)
at /Users/linus/.cargo/registry/src/github.com-1ecc6299db9ec823/synopsys-usb-otg-0.3.1/src/bus.rs:365
365 while read_reg!(otg_global, regs.global(), GRSTCTL, AHBIDL) == 0 {}
(gdb)
halted: PC: 0x08002ace
halted: PC: 0x08002ac6
Please check that clocks are correct and 48MHz clock is supplied to the USB peripheral.
I agree, it looks like there is a clock issue.. I'm looking into this and I'll come back to you. Thanks!
It appears that usb-device works when compiled with default rust, but it fails when compiled with nightly (no changes in the code, just added '+nightly' to the cargo build command). Should I open another issue for that? (FreeRTOS requires nightly because of the allocator, that's why I noticed it)
I think the best approach is to reduce the software to a minimal version which reveals the difference between stable and nightly and then file a bug to rust-lang
.
I ran into this as well.
Linking the related issue chain for reference, in case anyone else has the same issue: https://github.com/stm32-rs/stm32f4xx-hal/issues/567
I have been using this library on my STM32F405 and it has work flawlessly with interrupt polling: The setup is as follows:
However, now I am trying to use it with a FreeRTOS wrapper for rust which requires nightly build with a global allocator:
and now the USB setup fails, I assume the allocations conflict? Does anybody have an idea on how to mitigate this?