Open martinwork opened 4 years ago
Hi @martinwork
This is a good spot! it does indeed look like _etext is not a good indicator of the end of flash usage. Curious that the only GCC linker symbols of the data segment are the RAM pointers, but checking the linker script I agree that this is indeed the case.
Fix looks good to me.
MicroBitFileSystem uses FLASH_PROGRAM_END, rounded up to the next page to calculate the address to start storing the file system data in flash. https://github.com/lancaster-university/microbit-dal/blob/master/inc/core/MicroBitConfig.h#L109 https://github.com/lancaster-university/microbit-dal/blob/master/source/drivers/MicroBitFileSystem.cpp#L187
Using target bbc-microbit-classic-gcc, I've found that writing to flash at that address can sometimes cause a problem: after a reset, the firmware crashes very soon.
It appears that FLASH_PROGRAM_END = (&__etext) is the location for data copied to RAM in the initialisation code from startup_NRF51822.S (see below). When __etext is close to a page boundary, the usual rounding to the next page may not get past the initialisation data.
I think FLASH_PROGRAM_END should be defined something like the following, but I'm not sure this will always be safe. Is
__data_start__ >= __data_end__
always?FLASH_PROGRAM_END also occurs in MicroBitMemoryMap, used by MicroBitPartialFlashingService. I haven't checked whether fixing the calculation of FLASH_PROGRAM_END will cause a problem there.
From startup_NRF51822.S: