We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I am trying to get a custom bootloader to run from RAM only and so we modified our scatter file to be as follows:
LR_IROM1 0x00000000 0x00007FC8 { ; load region size_region ER_IROM1 0x00000000 0x00007FC8 { ; load address = execution address *.o (RESET, +First) *(InRoot$$Sections) } RW_IRAM1 0x1FFF0000 0x00010000 { ; RW data *(+RO) } RW_IRAM2 0x20000000 0x00010000 { ; RW data *(+RW, +ZI) } }
This appears to work when using the debugger, but not when flashed and run without the debugger. Is it possible that the debugger is copying the code from ROM to RAM? Shouldn't the C Startup library in __main be doing this? Do I need to specify something for this copy to take place?
Thanks, JD
You don't give too much detail. You did not specify your chip, but it do not seem to me that your scatter file makes sure any code is copied to RAM! Try adding +RO to RW_IRAM2. Besides, if your boot loader needs to program itself, you must also place the C standard libraries in RAM.
We are using a K60FN1M0VMD15.
The code (+RO) is should be copied to RW_IRAM1 (which is specified). RW_IRAM2 is for RW variables and ZI variables.
How can the C standard libraries be placed in RAM? At least part of the C standard libraries (the part that does the copying from ROM to RAM) can not be placed in RAM.
-JD
I forgot the exact syntax but it is demonstrated in the linker user manual.
A bootloader can't normally run from RAM - who would boot-strap it from flash to RAM?
OK if you run from battery-backed RAM.
When using the debugger, then the debugger can use a debugger script to set the PC to start of RAM after having downloaded the code into RAM.
The goal is to get all of the executing code into RAM, not for the ROM to be blank. I.e. it is ok for some code in ROM to initialize and copy code to RAM and then execute the code in RAM. At that point, the ROM can be re-loaded
At that point, the ROM can be re-loaded
Not if you want that boot loader to work reliably it can't. Just ask yourself: what will your CPU do if, while running from RAM, and some arbitrary fraction of the ROM having been re-loaded, the power fails? You now have no new program, and no old one either. So: nothing to boot your CPU from.
If you know of a way to avoid this issue, I'd be glad to hear it. As the Kinetis only supports sector erase, even if you loaded a new bootloader prior to erasing an old bootloader, at some point you have to change the reset vector for the processor to point to the new bootloader and the process could fail at that point too.
You make the boot loader so trivially simple that it doesn't need to be updated.
You need fancy communication etc? You make a secondary boot loader that do the fancy stuff.
Then this secondary boot loader can download a new application or a new secondary boot loader.
The minimal boot loader can either have a backup serial interface in case reprogramming fails. Or you can have two alternative copies of the more advanced boot loader so you program version 2 and can do rollback to version 1 if needed.
But you do really not want a system that clears the flash and bricks the unit. In real life, units will brick if you leave a security hole like that.
nothing to boot your CPU from
Not if you one has 2 bootloaders - one updatable, the other not...
If you know of a way to avoid this issue, I'd be glad to hear it
The way to avoid that issue is not to go there in the first place. The primary, if not the only, reason to even have a bootloader is that it should not change. Or, at the very least, change as infrequently as possible.
A boot loader that tries to reflash itself is an exercise in repairing the chair while you're sitting on it: if you're lucky it'll work, but if you're not you'll end up pulling bloody splinters of chair out of your back side.