Closed erwango closed 5 months ago
I've been looking at this issue and some things aren't clear to me.
I see that for the STM32F4 series it is possible to configure the write block size through bits 9:8 of the FLASH_CR
register. No problems here.
However, for the STM32F1 series, the documentation only mentions half-word write operations.
Taking a closer look at the flash_stm32f1x.c file and investigating the previous commits, it seems that in the past this file was used for the F0, F1, F3, L0 and L1 series. But I'm not sure if that's still the case. @erwango can you confirm it please? See #25245 and 21fe559eb76aa2b6b74260cd70a0fe6fd8311fa0.
Below is a summary of the supported block sizes for each series according to the information I found in the documentation.
Series | Supported block sizes | Reference |
---|---|---|
F0 | half-word | Section 3.2.2 of RM0091 |
F1 | half-word | Section 2.3.3 of PM0068 |
F3 | half-word | Section 4.2.3 of RM0316 |
F4 | byte, half-word, word, double word | Sections 3.3 and 3.9.7 of RM0090 |
L0 | byte, half-word, word | Section 3.2 of RM0377 |
L1 | byte, half-word, word, double word | Section 3.2 of RM0038 |
So, when you say to add per series variant of st,stm32-nv-flash
does that mean only for F1 and F4 series or for all the series above?
Having this clarified, I think I can tackle this issue.
Thanks @ggrs for looking into this. You're fully right, and this is now configured based on device tree compatible (st,stm32f1-flash-controller in case of this driver, used for f0, f1, f3, l0 and l1).
This means that F4 and L1 have the possibility to configure block size. So a new compatible (ex: st,stm32f4-nv-flash
) would apply to L1 and F4.
Is your enhancement proposal related to a problem? Please describe. https://github.com/zephyrproject-rtos/zephyr/pull/67919 introduces configurable write-block-size support in STM32F4 flash driver. This possibility was already available on STM32F1 flash driver.
This could be useful from application side as it can speed up flash writes. Issue is that this possibility is not documented outside driver and it is likely that most users will miss this.
Describe the solution you'd like Document this property behavior in a binding. Besides, since only a specific range of values are supported, it would be nice to re-define it from int to enum.
Hence, proposal is to add per series variants of
st,stm32-nv-flash
with newwrite-block-size
prop defined as an enum with proper description.