I made a program to load applications to RAM and run them in the Stellaris Launchpad. On reset, it reads an SREC file from the serial port and copies it to RAM. It points the vector table to the load location (so interrupts work normally) and jumps to the application’s
The first problem was reserving RAM for the loaded application. To do this, I modified my linker script by splitting the RAM into two sections, and keeping the loader in the first section.
Afterwards, the application has to be linked so that it will run from RAM. This means using another linker script that puts it on the second section of RAM. It also places the vector table at the beginning so that the loader knows where it is.
The loader itself is a minimal SREC parser which implements the records that showed up in my SREC files.
To play around with the loader, it’s possible to make SREC files from the SDK example projects. This requires changing the entry point and linker script in the Makefile. For example, to compile project0 we change
. Then we have to change the startup script in
startup_gcc.c . Normally the reset routine would copy data from Flash to RAM to initialize variables, but this isn’t necessary when running from RAM. So comment out
ResetISR and change the reset vector to
(void (*)(void) main.
After these changes, the AXF file generated by
make will be good for running from RAM. To get the SREC file, use
sed to strip the header:
arm-none-eabi-objcopy -S -O srec --srec-len=8 project0/gcc/project0.axf project0/gcc/project0.srec
# Strip header
sed -i /^S0/d project0/gcc/project0.srec
I’ve automated this last step with a rule in the Makefile. This works successfully with
qs-rgb and probably all the other example projects.