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

Forever waiting for AHB clock in nightly #33

Closed
hacknus opened this issue Jan 10, 2023 · 5 comments
Closed

Forever waiting for AHB clock in nightly #33

hacknus opened this issue Jan 10, 2023 · 5 comments

Comments

@hacknus
Copy link

hacknus commented Jan 10, 2023

Original issue, was redirected here.

I tried both USB-examples on my STM32F405; poll and interrupt and both work with rust stable (rustc 1.66.0 ) but hang with nightly (rustc 1.68.0-nightly).
By using the debugger, I notice that I get stuck in this line:

// Wait for AHB ready
while read_reg!(otg_global, regs.global(), GRSTCTL, AHBIDL) == 0 {}

line 365 in .cargo/registry/src/git.luolix.top-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/git.luolix.top-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/git.luolix.top-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/git.luolix.top-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

it seems in --release some stuff is optimized out, but it gets stuck at the same point in debug:

linuss-MacBook-Pro:stm32-usb-rust linus$ arm-none-eabi-gdb -q -ex "target remote :3333" target/thumbv7em-none-eabihf/debug/stm32-usb-rust
Reading symbols from target/thumbv7em-none-eabihf/debug/stm32-usb-rust...
Remote debugging using :3333
core::ptr::read_volatile<u32> (src=0x500000d8) at /rustc/659e169d37990b9c730a59a96081f2ef7afbe8f1/library/core/src/ptr/mod.rs:1523
1523	/rustc/659e169d37990b9c730a59a96081f2ef7afbe8f1/library/core/src/ptr/mod.rs: No such file or directory.
(gdb) step
halted: PC: 0x08013160
halted: PC: 0x08003590
halted: PC: 0x08003592
synopsys_usb_otg::bus::{impl#2}::enable::{closure#0}<stm32f4xx_hal::otg_fs::USB> (cs=0x2000971c)
    at /Users/linus/.cargo/registry/src/git.luolix.top-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: 0x08003594
halted: PC: 0x08003596
halted: PC: 0x0800359a
halted: PC: 0x08003580
halted: PC: 0x08003582
halted: PC: 0x08003584
365	            while read_reg!(otg_global, regs.global(), GRSTCTL, AHBIDL) == 0 {}
(gdb) 
synopsys_usb_otg::target::UsbRegisters::global (self=0x20009c38)
    at /Users/linus/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/synopsys-usb-otg-0.3.1/src/target.rs:51
51	        unsafe { &*(self.0 as *const _) }
(gdb) 
halted: PC: 0x08003586
synopsys_usb_otg::bus::{impl#2}::enable::{closure#0}<stm32f4xx_hal::otg_fs::USB> (cs=0x2000971c)
    at /Users/linus/.cargo/registry/src/git.luolix.top-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: 0x08003588
halted: PC: 0x0800358a
halted: PC: 0x0800358c
synopsys_usb_otg::ral::register::RWRegister<u32>::read<u32> (self=0x500000d8)
    at /Users/linus/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/synopsys-usb-otg-0.3.1/src/ral/register.rs:23
23	        unsafe { ::core::ptr::read_volatile(self.register.get()) }
(gdb) 
halted: PC: 0x08013154
Note: automatically using hardware breakpoints for read-only addresses.
core::ptr::read_volatile<u32> (src=0x500000d8) at /rustc/659e169d37990b9c730a59a96081f2ef7afbe8f1/library/core/src/ptr/mod.rs:1521
1521	/rustc/659e169d37990b9c730a59a96081f2ef7afbe8f1/library/core/src/ptr/mod.rs: No such file or directory.
@hacknus

This comment was marked as outdated.

@antonok-edm
Copy link

antonok-edm commented Jan 14, 2023

I just tested this in Beta and it's also broken there. I think it's worth filing an issue with rust-lang.

Edit: filed rust-lang/rust#106830

@adamgreig
Copy link
Member

As @hacknus said, in nightly this line hangs: while read_reg!(otg_global, regs.global(), GRSTCTL, AHBIDL) == 0 {}

The GRSTCTL register is at address 0x50000010, and AHBIDL is bit 31. On my F411 reproducing this issue, that memory address is 0x80000000 (AHBIDL set) as you'd expect, but the disassembly around that region indicates the code's actually reading from 0x500000d8. No idea why yet.

(gdb) frame
#0  synopsys_usb_otg::bus::{impl#2}::enable::{closure#0}<stm32f4xx_hal::otg_fs::USB> (cs=<optimised out>) at /home/adam/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/synopsys-usb-otg-0.3.1/src/bus.rs:365
365	           while read_reg!(otg_global, regs.global(), GRSTCTL, AHBIDL) == 0 {}
(gdb) x 0x50000010
0x50000010:	0x80000000
(gdb) x 0x500000d8
0x500000d8:	0x00000000
(gdb) info reg
R0             0x50000000          1342177280
R1             0x0                 0
R2             0x0                 0
R3             0x10                16
R4             0x0                 0
R5             0x40020000          1073872896
R6             0x2000fd60          536935776
R7             0x2000ffec          536936428
R8             0xffffff80          4294967168
R9             0x0                 0
R10            0x2000fbc8          536935368
R11            0xffffff81          4294967169
R12            0x0                 0
SP             0x2000fb64          0x2000fb64
LR             0x8001511           134223121
PC             0x800152a           0x800152a <f4usb::__cortex_m_rt_main+1598>
XPSR           0x61005800          1627412480
FPSCR          0x0                 0
MSP            0x2000fb64          536935268
PSP            0x0                 0
0800151e  d0f8d820   ldr     r2, [r0, #0xd8]
08001522  002a       cmp     r2, #0
08001524  5cbf       itt     pl
08001526  d0f8d820   ldr     r2, [r0, #0xd8]
0800152a  002a       cmp     r2, #0
0800152c  04d4       bmi     #0x8001538

@adamgreig
Copy link
Member

I think this is a bug in the RAL included in this crate; the RegisterBlock structs are not marked repr(C) (see adamgreig/stm32ral@fc07b98 and imxrt-rs/imxrt-hal#13) so the compiler is in principle free to rearrange them, which it seems is happening here.

Adding #[repr(C)] to all the RegisterBlocks and rebuilding seems to resolve the issue.

Not sure what commit in rust-lang exactly triggered this, looks like @antonok-edm has narrowed it down to between nightly-2022-11-19 and nightly-2022-11-24.

@antonok-edm
Copy link

@Disasm Disasm closed this as completed in 845636e Jan 14, 2023
Disasm added a commit that referenced this issue Jan 14, 2023
Add repr(C) to all RegisterBlocks, fixes #33
@Disasm Disasm mentioned this issue Jan 14, 2023
jackronaldi pushed a commit to lightning-signer/validating-lightning-signer that referenced this issue Oct 15, 2024
relevant issues:
- stm32-rs/synopsys-usb-otg#33
- stm32-rs/stm32f4xx-hal#574

repr(C) required otherwise layout is optimized by rust compiler
Signed-off-by: Lakshya Singh <lakshay.singh1108@gmail.com>
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

3 participants