mtthw-meyer / libdaisy-rust

Hardware Abstraction Layer implementation for Daisy boards
MIT License
51 stars 18 forks source link

examples do not work since update to stm32h7xx-hal 0.14 #36

Closed zer0-droids closed 11 months ago

zer0-droids commented 1 year ago

Hello,

When I try to flash my daisy board with an example (for instance blinky), the program does not start.

It works if I revert to stm32h7xx-hal 0.13.1 with the following patch:

--- a/Cargo.toml
+++ b/Cargo.toml
@@ -19,8 +19,8 @@ debouncr = "0.2.2"
 log = "0.4.11"
 micromath = "1.1.1"
 panic-halt = "0.2.0"
-stm32h7xx-hal = { version = "0.14.0", features = ["stm32h750v","rt","fmc", "xspi", "sdmmc", "sdmmc-fatfs", "usb_hs"] }
-stm32-fmc = "0.3.0"
+stm32h7xx-hal = { version = "0.13.1", features = ["stm32h750v","rt","fmc", "xspi", "sdmmc", "sdmmc-fatfs", "usb_hs"] }
+stm32-fmc = "0.2.0"
 rtt-target = { version = "0.4.0", optional = true }
 panic-rtt-target = { version = "0.1.2", features = ["cortex-m"], optional = true }
 lazy_static = { version = "1.4.0", features = ["spin_no_std"], optional = true  }

The issue seems to happen quite early at initialization: I tried to reduce the system::System::init() method to a minimal code that blinks a led, and it does not blink with 0.14.0 (while it blinks with 0.13.1).

I use rust 1.70.

Is anyone else seeing the same issue? please @dobrite, can you confirm it's working on your side?

zer0-droids commented 1 year ago

After digging a bit, it appears that the issue is related to init_clocks(). If I decrease the frequency of sys_ck, or if I remove the PLL3 configuration, I can see my early LED blink again.

I reproduced the issue in a pure stm32h7xx-hal example, outside libdaisy-rust. The behavior is the same: the initialization fails with 0.14.0 and succeeds with 0.13.1. I'll try a git bisect to find the commit which is the origin of the failure.

zer0-droids commented 1 year ago

Actually, it was a panic but I did not see because on my application, my panic handler uses panic-persist, which requires to pass the early init...

So, the panic is: panicked at 'Cannot achieve output frequency this low: Maximum PLL divider is 128', /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/stm32h7xx-hal-0.14.0/src/rcc/pll.rs:36:5

And the origin commit is: https://github.com/stm32-rs/stm32h7xx-hal/commit/149e84357e319cc4f23d9f0042b5e48cb9aaede7

It seems that the HAL is not able to find a valid divider value for PLL3_Q or PLL3_R. It was probably failing before 0.14.0, but was silently ignored. I'll submit a pull request soon.

zer0-droids commented 1 year ago

I submitted pull request #37