In many cases I do a full erase-flash-debug cycle: I get my embedded microcontroller flash completely erased and then programmed with my application. Well, that does not work that way if I program with a bootloader. Yes, I can flash the bootloader and then load my target application with the bootloader, but that’s not the scenario I want to use in the development phase. I want to flash my application and keep the bootloader on the target. This means: I need to do erase and program a part of the memory. But how to do this?
Background: My application runs on the TWR-LCD board. The ColdFire MCF51JM128 enumerates as MSD (Mass Storage Device) on the USB bus in booloader mode. That way I can simply copy an S19 file from the PC to the target and it will flash that file. The bootloader is implemented with Processor Expert components and is available here.
The following picture shows the memory map and shared areas between the bootloader and the application:
Bootloader and Application Memory Mapping
So flashing the application on top of the bootloader means that I should not erase the flash below 0x4800. I need to tell the debugger this. The solution is to use the P&E Multilink with the ‘Advanced Programming Option’:
Advanced Programming Option
This gives me the option I need to preserve one or multiple memory ranges:
Preserve Memory Range
There are other powerful options too. If use ‘Enable Flash Programming Dialog’ then get the following dialog during programming:
CPROGCFV1 Programmer Dialog
The good thing is: it shows that my flash protection works: the Debugger and P&E Multilink are preserving my data range, erasing things and then restore the content again: that way the preservation is not limited to the physical device flash block boundaries. Really, really cool!
The only not-so-good thing with this dialog is: it is visible only during the script execution, and closes right afterwards. So it might go so fast that you do not have any chance to read what is going on. But there is rescue: I need to have logging enabled (see as well Debugging rules):
Enable Logging
With logging enabled, I get the messages as well in the Console view:
Console View showing preserved memory range
With that, I do not need to have the ‘Enable Flash Programming Dialog’ enabled. I get the full information to the Console View anyway with logging. And this is what I need to see. And with the Advanced Programming Option I can program only part of my flash
Happy flashing in parts 🙂
MCU on Eclipse 
Pingback: Flashing with a Button (and a Magic Wand) | MCU on Eclipse
Pingback: Page not found | MCU on Eclipse
Thanks a lot for the very useful hint.
I followed the steps described here and achieved preservation of a range of flash memory on my K60DN512 but it was painfully slow compared with no range preservation.
A bit of background: I have CW 10.2.4 and a P&E micro multilink FX. Without range preservation writing a image (of about 50Kb) in flash takes a few seconds (about 15s) but with range preservation (only memory range 1, from 0x40000 to 0x7FFFF) writing the same image takes more than 5 minutes! (320s average in several of my tests). I try to keep the multilink FX up-to-date (current firm. is 705) so I suspect it’s a codewarrior problem.
Any thoughts on this issue will be really useful.
LikeLike
I think the P&E ‘preservation’ algorithm really loads all the preserved bytes, then does a full erase and then programs the whole thing again. Which needs time.
Have you considered to use a Target Task instead? At least I see that here I could erase on a block level, and that way would avoid the whole backup thing.
LikeLike
Pingback: How (not) to Secure my Microcontroller | MCU on Eclipse
Pingback: Adding Symbols to the CodeWarrior Debugger | MCU on Eclipse
Hello,
I just saw this great option. Does the configuration is saved in project file or in worksapace?
For example: I have two projects on same workspace: Application and Bootloader.
I want to set memory preservation range for each of the project. Of course each project should have its own preservation range.
Thanks.
LikeLike
Yes, the settings are stored in the .launch file (typically located inside the Project_Settings\Debugger project folder).
That way you can have two different (Eclipse) launch files: one for the application and one for the bootloader.
LikeLike
Hi Erich,
Do you know how to protect FlexNVM regions? I am using the EEE+DFlash Backup feature of Kinetis and I would like to preserve the DFlash region from being cleared when reprogramming the device. I have tried protecting the region from 0x10000000-0x13FFFFFF, but the code seems to start in a weird place when I do that:
No source available for “0xFFFFFFFE (0xFFFFFFFE)() ”
I didn’t realize I was clearing the NVM every time I reprogrammed, so it took me a few days to realize I was actually initializing the EEE feature correctly…it just wasn’t persisting between debugging sessions.
Thanks!
Vishal
LikeLike
Hi Vishal,
I have not used that feature (yet?). All what I used was protecting flash memory areas using the NVM settings.
LikeLike
Anyone tried using the “preserve flash region” on a region near the end of their flash?
Works beautifully for me for the flash areas near the start – but does not function at all if for example asking the system to preserve the last sector of flash.
Tried 2 different boards with the same result.
LikeLike
I’m using it as well to preserve my flash and for the FRDM-KL25Z (I have data from 0x1FC00 to the end), and this works for me?
LikeLike
Pingback: Preserving Memory Ranges with Eclipse and P&E GDB Server | MCU on Eclipse
How I can do this with kinetis design studio?
LikeLike
For P&E Multilink, see https://mcuoneclipse.com/2014/07/13/preserving-memory-ranges-with-eclipse-and-pe-gdb-server/
LikeLike
Hi Erich,
Thanks for writing this stuff up. By combining some of your posts, I managed to come up with a set of steps for storing config data to flash and easily accessing that data in C using Kinetis Design Studio + SEGGER J-Link on an NXP Freedom board.
The config data survives rebuild + reflash of the target, which was initially a problem, as KDS has no easy way to protect specific flash regions.
The config data can be cleared (to 0xFFs) by erasing the entire chip (unfortunately the only option available via JLink.exe).
Documented here: https://vilimpoc.org/blog/2016/12/25/flash-based-configuration-data-using-the-ld-linker/
Cheers,
Max
LikeLike
Hi Max,
thank you very much for sharing this, very helpful! With P&E there is a way to protect memory ranges (https://mcuoneclipse.com/2014/07/13/preserving-memory-ranges-with-eclipse-and-pe-gdb-server/, that article was originally written for a ‘manual’ way, now there is a dialog). For Segger I have not found a better way.
LikeLike
Thanks. Yeah, for Segger the only way I found was literally to move my data out of Segger’s way. But at least that works.
I’m aware that on some NXP chips there are flash protection bits that may be set on the chip itself, which also forces a full flash erase if those areas are attempted to be written later, but that’s not quite the solution I was looking for.
LikeLike
Hi Erich,
So if I am using the Segger J-link will it overwrite my 2k block of ”eeprom” area that I saved at the top of flash? (I know how to make it work right with the PE multilink, but I am unsure if the Segger is going to erase all of flash every time I program (even though I only have 80k of code in a 512k part (K22FN512)).
Brynn
LikeLike
Hi Brynn,
by default, the Segger software will only erase and program the Flash/memory blocks which are present in the binary/elf file. So in your case it will only program these 80k of flash you have in your file.
Erich
LikeLike