Flash changes #104
Flash changes #104
Conversation
usbalbin
force-pushed
the
flash_changes
branch
from
6d6447a
to
a26f66b
Compare
usbalbin
force-pushed
the
flash_changes
branch
from
a26f66b
to
7f71d41
Compare
| pll_config.mux = stm32g4xx_hal::rcc::PLLSrc::HSI; // 16MHz | ||
| pll_config.n = stm32g4xx_hal::rcc::PllNMul::MUL_32; | ||
| pll_config.m = stm32g4xx_hal::rcc::PllMDiv::DIV_2; // f(vco) = 16MHz*32/2 = 256MHz | ||
| pll_config.r = Some(stm32g4xx_hal::rcc::PllRDiv::DIV_2); // f(sysclock) = 256MHz/2 = 128MHz |
There was a problem hiding this comment.
Correct me if I am wrong but the clock setup is not really needed for this example, right? Thought I'd remove all but the essentials to give more focus on the flash related things
| flash.acr.modify(|_, w| { | ||
| w.latency().bits(0b1000) // 8 wait states | ||
| }); | ||
| } |
There was a problem hiding this comment.
Even with the custom clock setup above, this should not really be needed, right? This should be done automatically here when setting the clock settings. However by my math, the auto-thing would set it to 4 wait states for a f_sys of 128MHz. Does it for some reason need to be 8, or is that incorrect?
| @@ -48,21 +47,22 @@ pub enum FlashSize { | |||
| Sz1M = 1024, | |||
| } | |||
| impl FlashSize { | |||
| const fn kbytes(self) -> u32 { | |||
| const fn bytes(self) -> u32 { | |||
There was a problem hiding this comment.
Changed this to bytes since, from what I can tell really returns a value in units of bytes
| SZ_1K * self as u32 | ||
| } | ||
| } | ||
|
|
||
| pub struct FlashWriter<'a, const SECTOR_SZ_KB: u32> { | ||
| pub struct FlashWriter<'a, const SECTOR_SIZE: u32> { |
usbalbin
force-pushed
the
flash_changes
branch
from
f40c431
to
e3f7687
Compare
|
I just had a sneak peak at stm32h7xx-hal which puts memory fences in the |
|
I will try to re-visit this at a later time |
(This PR contains too many unrelated commits, will clean that up)- DoneNoticed some weird things when trying to use the flash on a nucleo-g474. Some of it related to dual bank but not not all of it...
At some point i got the feeling that reading during the verify-thing in
page_eraseandwritegave weird values back as if there were some race condition or maybe wrong data width or something... Will try to find the problem.