STM32H7: Flash error flags are set spontaneously #60449
Comments
|
Just noted the comment in this discussion, that such behavior can be triggered by speculative access to the system memory. Indeed adding the following MPU region seems to resolve the issue at least in our sample: Beforehand I already tried setting up a background region as suggested by ST in this tutorial. For unknown reasons they don't protect the system memory in this example. Anyway the solution to the issue here could be to define a reasonable background MPU region. |
|
Thanks for raising this. |
|
also The interrupt occurs even when the SECURITY option byte and the secure protection are OFF. The https://community.st.com/t5/stm32-mcu-products/spurious-rdperr-and-rdserr-when-all-protection-and-security/td-p/279852 gives some clarifications : |
|
We've also been observing this behaviour on our STM32H743 when communicating with the bootloader API. Would be great to have this fixed. |
The PR #60765 fixes for all the stm32H7, isn't it. |
The STM32H7 is haunted/contains an errata where the CPU may speculate into a system area (`0x1ff0_0000`) and trigger a flash error normally only seen when security features are enabled. This is not an official errata but seems to be well(?) reported https://community.st.com/t5/stm32-mcus-products/spurious-rdperr-and-rdserr-when-all-protection-and-security/td-p/279852 zephyrproject-rtos/zephyr#60449 One suggested workaround is to add an extra MPU region which marks The Danger Zone as NX. For the way hubris is designed this isn't plausible. Instead clear any errors before we attempt to write to flash.
The STM32H7 is haunted/contains an errata where the CPU may speculate into a system area (`0x1ff0_0000`) and trigger a flash error normally only seen when security features are enabled. This is not an official errata but seems to be well(?) reported https://community.st.com/t5/stm32-mcus-products/spurious-rdperr-and-rdserr-when-all-protection-and-security/td-p/279852 zephyrproject-rtos/zephyr#60449 One suggested workaround is to add an extra MPU region which marks The Danger Zone as NX. For the way hubris is designed this isn't plausible. Instead clear any errors before we attempt to write to flash.
The STM32H7 is haunted/contains an errata where the CPU may speculate into a system area (`0x1ff0_0000`) and trigger a flash error normally only seen when security features are enabled. This is not an official errata but seems to be well(?) reported https://community.st.com/t5/stm32-mcus-products/spurious-rdperr-and-rdserr-when-all-protection-and-security/td-p/279852 zephyrproject-rtos/zephyr#60449 One suggested workaround is to add an extra MPU region which marks The Danger Zone as NX. For the way hubris is designed this isn't plausible. Instead clear any errors before we attempt to write to flash.
The STM32H7 is haunted/contains an errata where the CPU may speculate into a system area (`0x1ff0_0000`) and trigger a flash error normally only seen when security features are enabled. This is not an official errata but seems to be well(?) reported https://community.st.com/t5/stm32-mcus-products/spurious-rdperr-and-rdserr-when-all-protection-and-security/td-p/279852 zephyrproject-rtos/zephyr#60449 One suggested workaround is to add an extra MPU region which marks The Danger Zone as NX. For the way hubris is designed this isn't plausible. Instead clear any errors before we attempt to write to flash.
Describe the bug
Summary: The RDSERR (secure error) and/or RDPERR (read protection error) flags of the flash status register are set from time to time.
We noticed this issue in our project because the bootloader API
mcuboot_swap_type()would return something unexpected. Under the hood this function usesflash_area_read()which is provided by the STM32 flash driver. This one in turn checks the above mentioned error flags after execution which leads to a failure.To Reproduce
From our project we extracted a sample to reproduce the issue. After quite some playing around we now have a minimal sample which does actually nothing except very short sleeps in the main thread. Before running the loop with sleeps the sample registers an interrupt to get notified if the mentioned flash error flags are set.
It can be found here: https://github.com/mjaun/zephyr/tree/flash_error/samples/flash_error
It reproduces the issue at least on the
nucleo_h743ziboard and also on thenucleo_h743zi_minimalboard which is provided on the same branch and disable almost all drivers.Expected behavior
Impact
We have some workarounds in place, because the bootloader API might not work properly.
Logs and console output
Output from the mentioned sample:
The timings are always the same also across multiple devices. Note that the time between each occurrence is always almost the same. I observed the timings changing by modifying SYSCLK or also changing the application code. Some changes make the issue disappear (e.g. enabling CONFIG_LOG or CONFIG_DEBUG).
Currently I don't have a clue why these errors occur at all. Breaking in the ISR shows that the application is in idle thread.
Environment (please complete the following information):
The text was updated successfully, but these errors were encountered: