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

boot not compatible with STM32L0x1 device family #3342

Open
kingofpayne opened this issue Sep 16, 2024 · 0 comments
Open

boot not compatible with STM32L0x1 device family #3342

kingofpayne opened this issue Sep 16, 2024 · 0 comments

Comments

@kingofpayne
Copy link
Contributor

Erasing a flash memory page in STM32L0x1 devices results in bytes set to 0x00 instead of the usual convention that erasing flash leads to 0xFF. I found this while trying to make embassy-boot work on a STM32L081 chip, and there is no clear indication from ST on this behaviour in the reference manual. The only evidence I can provide is, from RM0377, the presence of the NOTZEROERR flag in the FLASH_SR register, whose description is:

This bit is set by hardware when a program in the Flash program or System Memory tries to overwrite a not-zero area.

The issue is that erasing the bootloader state partition results in an invalid state, making the bootloader unable to swap to the DFU as it believes the swap has been attempted and failed, triggering a rollback where it is not possible. To make embassy-boot work on my device, I had to patch the following line and replace the constant with the value 0x00:

pub(crate) const STATE_ERASE_VALUE: u8 = 0xFF;

So it is somewhat expected that the current code is subject to improvement and not ready for all devices yet. Not blaming embassy here as the constant is not yet part of the NorFlash trait (see his issue in embedded-storage). I even have to note that it was a great experience to see such a magic constant, whose only modifications fixed everything!

There is one example using embassy boot in examples/boot/application/stm32l0 which I think can be misleading, as I don't expect this to work properly (has anyone tested it?).

While the NorFlash trait does not provide enough information yet, an option to define the expected erase value would be helpful, either set at runtime or via a feature?

kingofpayne added a commit to kingofpayne/embassy that referenced this issue Sep 16, 2024
Allow compatibility with devices whose flash erase set bytes to 0x00
instead of 0xFF, using a new flash-erase-zero feature.
See issue embassy-rs#3342.
Dirbaio pushed a commit that referenced this issue Sep 16, 2024
Allow compatibility with devices whose flash erase set bytes to 0x00
instead of 0xFF, using a new flash-erase-zero feature.
See issue #3342.
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

1 participant