Hi,
I'm using Arm DS Version: 2022.2 as a trial version.
I've no arm chip yet thus i'm using Cortex-M55 FVP.
I'm trying to write kind of a boot rom sw that runs and load another 'hello world' application into code and data to different execution addresses in memory.
After boot rom ends with loading the code and data into memory it jumps into the 'hello world' Reset_Handler address and starts execution.
So far so good, the 'hello world' begin to run but I've noticed that the "__scatterload_copy" from arm c library is overwriting the RW data section with default pattern of 0xDFDFDFCF.
As a result a "SystemCoreClock" variable from "system_ARMCM55.c" initial value is being overwritten from "0x17D7840" into 0xDFDFDFCF and code based on this variable isn't working as expected..
I would be happy to understand how to avoid the "__scatterload_copy" operation in order not to overwrite the data the boot rom already loaded into data memory?
Thanks,Ronen
Hi Ronan,
I got your point, thanks.
I've tried that and really the scatter load does nothing as expected. However the hello world isn't working as expected (SystemCoreClock isn't initialized to its default data value - this is also understood - we skipped the scatter load).
Feels like a ctach-22.
Ronan, sorry but maybe I'm missing something here, I will try again:How a typical boot rom application (that gets its destination fw binary data+code through external host, flash memory etc) can branch (and not returned) to its fw application and continue running from there?My understanding is that the boot rom accepts the fw code+data, copy it into a different memory locations (according to the fw scatter file definition and sizes) and branch into the fw application entry point,.
Thanks for your great support.Finally it worked for me.
The turning point was your last suggestion to skip the scatter load functionality from the hello world app itself.Rather than that i had two other bugs:1. I was branching into the vector section instead to the Reset_Handler (i.e. my Image Entry point was wrong).2. The hello world Code section (as an array in the boot rom) was wrong (different than the code we saw in disassembly). That happened due to a wrong path.