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
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.