2022-08-09 09:35 PM
Does doing a simple write to the flash address space not result in any kind of a BusFault or other error interrupt?
After debugging an issue wherein I did not realize that I was running `qsort` on const data that was residing in the, I was a little surprised to find this apparent behavior.
Is it really the case that doing a write to this address range, without the flash being "unlocked", that the write is just silently ignored?
Something as simple as:
volatile void* ptr = (volatile void*)0x08000000;
*((int32_t*)ptr) = 0x1234;
This is on an STM32L4 line part, although I expect this will be similar across all STM32 M3/M4 parts.
2022-08-10 07:58 AM
Enable the MMU and set up flash ranges as read only. I also mark 0x0 as "no access" to catch NULL pointer dereferences. Though you have to be careful on chips that map 0x0 to the Flash space on bootup. It is either FreeRTOS or LwIP (I don't recall which) that try to access the starting stack pointer value by reading the first entry in the vector table, and on some chips the default VTOR pointer points to zero.
2022-08-10 08:28 AM
Oh, right, there is always the MMU.
The minor complication there is that one range of our internal flash is used for mutable NVM storage. (why don't more chips have an EEPROM like the L0's?)
But that does have a fixed address range.
And it looks like the QSPI will also not generate a BusFault when in memory-mapped mode, only before the address setup happens, if I am reading all the docs correctly.
So, at the very least, I could/should enable MMU for the fixed code region and the QSPI region in development builds, to catch mistakes like this.