Preserving Memory Ranges with Eclipse and P&E GDB Server

Posted on July 13, 2014 by Erich Styger

For my boot loaders I need the functionality that I can keep memory ranges from being erased while downloading the rest of the application. P&E provides a GDB server which interfaces with their probes (P&E Universal Multilinks, Tracelinks, …) and as well with the OpenSDA present on many of the Freescale evaluation boards. In CodeWarrior there is an option for ‘Advanced Programming Options’ which allows to preserve memory of the microcontroller FLASH (see “Programming part of flash“). However, that option or button is not present in the Eclipse version of the P&E GDB server (e.g. in Kinetis Design Studio). So how can I preserve some areas of FLASH in Eclipse with GDB?

Preservation of Non-Volatile Memory in CodeWarrior

UPDATE: Preserving Memory Ranges with P&E

With the most recent P&E Plugins (as of 9-May-2016), presevering memory ranges is now possible :-). Inside the debugger launch configuration, there is an Additional Options section with an Advanced Options button:

P&E Advanced Options

Behind this button, I can preserve memory ranges:

Non-Volatile Memory Preseveration

First Try: Launch Configuration Files

First, I was checking where the settings for memory preservation are saved. The debug connection stores its settings in a launch (.launch) configuration file. So I configured a connection to preserve memory areas. Comparing the .launch file before and afterwards shows the values in the .launch file:

Preservation Values in Launch Configuration File

So there are three different attributes involved:

PRESERVE<number>_ACTIVE set to “1” (enabled) or “0” (disabled).
PRESERVE<number>_START is the start address in decimal format.
PRESERVE<number>_END is the end address in decimal format.

With this knowledge, I thought that I can apply the same entries to the .launch files used by P&E for their GDB server implementation:

Enable sharing of the launch configuration, see “Sharing Debug Configuration with Eclipse“.
Open the launch configuration file with a text editor and add the needed string attributes to it:
Launch Configuration Files in Eclipse

Well, things came to a screeching stop at this point. Unfortunately the settings the P&E GDB Server .launch files were kind of similar to the ones in their CodeWarrior implementation. But different. I tried guessing and poking around the different string attributes, but….. I had to gave up :-(. Ahhhhhhrggggg!

PRESERVE_RANGE

Well, my wife could tell you that I can get really grumpy if I know that something ‘has to be possible somehow’, but it does not work. I don’t like to give up (anyone does?)!

So I did another round of poking and googling, and stumbled over a P&E application note from 2008: “New Programming Feature For Non-Volatile Memory – Preserve Range”. And that article opened the door to do what I need :-).

Basically, that article describes that PRESERVE_ENTRIES can be added to the flash programming applet files. But it does not find where these files are. So here we go…

Locating Flash Applet File

When I do debugging, the P&E GDB debugger writes messages to a debug console. Switch to that console with the small menu behind the triangle:

P&E GDB Debugger Console (click to enlarge)

This console shows where the GDB Server executable and files are located inside the Eclipse\plugins directory:

P&E GDB Server Location (click to enlarge)

Browse to that folder on your disk (I can copy paste the path/text from the console output). In that folder, there is a ‘gdi’ and one level down a ‘P&E’ folder. For Windows it is inside ‘Win32’, on Linux it is inside the ‘lin’ folder:

P&E Folder with Flash Programming Files

Inside that folder, search for the microcontroller you are dealing with. In this example I’m working with the KL25Z:

KL25Z Files in the P&E Folder

The flash programming files are the *.arp files, and they are simple text files. I’m using the KL25Z128. So it must be either the

freescale_kl25z128m4_1x32x32k_pflash.arp

kl25z128m4_pflash_pipeline.arp

Both Files are similar:

Flash Programming Files

So which one is used? For this I have a look at the console output

Console Log showing which Flash Programming applet is used

So with this I know which flash programming file is used :-).

I open that file in a text editor and search the line with NO_BASE_ADDRESS.

💡 In any case, I recommend to make a backup of the file before doing any change.

After that line I add a PRESERVE_RANGE line:

Added preserve range

Do *not* change the NO_BASE_ADDRESS line. Multiple PRESERVE_RANGE lines can be added. The PRESERVE_RANGE line states as first number the start address offset (from NO_BASE_ADDRESS), and the second number is the end address offset (again from NO_BASE_ADDRESS).

💡 See details in “New Programming Feature For Non-Volatile Memory – Preserve Range” about the address calculation.

With this change, I should now see that this memory range is preserved:

Re-programming preserved data range message

💡 Notice the warning about the modified CRC16. This makes sense, as I have modified the file. I think the last two bytes in the file are the checksum.

To disable the change, I can either restore my backup file, or comment the change in the file.

Summary

Preserving memory ranges in Eclipse with P&E GDB is not that simple with a dialog as in CodeWarrior. But very powerful for me after I have understood what needs to be done. It would be nice to have this in a dialog as in CodeWarrior, but until then, I have a way to make it happen.

Happy Preserving 🙂

15 thoughts on “Preserving Memory Ranges with Eclipse and P&E GDB Server”

Karibe on July 14, 2014 at 09:34 said:

This is very important information for anyone who want to do custom bootloaders and may be making a debuger for arm. thanks for sharing, makes one more thing easier, though I do not use P&E much, mostly openocd works for me, will check if it supports this.

LikeLike

Reply ↓
Karibe on July 14, 2014 at 10:43 said:

Apparently, there is now a seperate OpenOCD debug plugin gnuarmeclipse.livius.net/blog/openocd-debugging/ with full configuration pages.

There is a command in openOCD “Command: flash protect num first last (on|off)” but thats it, on or off. In openocd board specific scripts, you define the flash banks, and then you set protection on using this command, it will protect starting at sector ‘first’ and continuing up to and including ‘last’ of the bank defined. I guess thats it, you have to go mess with the scripts and its not provided in the openOCD plugin GUI as part of integration 😦

LikeLike

Reply ↓
Vishal on August 19, 2014 at 02:48 said:

Hi Erich,

Do you know if there are plans to support this natively in future versions of the plugin?

Thanks.

LikeLike

Reply ↓
- Erich Styger on August 19, 2014 at 07:52 said:
  
  Hi Vishal,
  I had asked P&E if they could do this in future version of their tools, but I don’t know if and when this will happen.
  Erich
  
  LikeLike
  
  Reply ↓
  - Ruben Jönsson on May 9, 2016 at 09:20 said:
    
    It is available now.
    /Ruben
    
    LikeLike
    
    Reply ↓
    - Erich Styger on May 9, 2016 at 13:18 said:
      
      Hi Ruben,
      indeed, things have been changed after that post. I have the article updated now.
      Thanks!
      Erich
      
      LikeLike
Vishal on August 19, 2014 at 03:38 said:

Also, have you been able to actually debug this application successfully with those options? That is, can you debug the app without a bootloader at all?

So far every attempt to debug the application without a bootloader has resulted in GDB displaying garbage addresses like 0xfffffffe and not being able to step through the code. We have set the startup PC in the GDB settings to what it should be for our application, and in the GDB logs we see:

992,494 36^done,stack=[frame={level=”0″,addr=”0x0001ba54″,func=”__thumb_startup”,file=”../Project_Se\
ttings/Startup_Code/startup.c”,fullname=”\\Controller_v3_KDS\\Controller_MK20DX25\
6VLK7\\Project_Settings\\Startup_Code\\startup.c”,line=”211″}]

So at the very least something seems to be happening right, but immediately after a disassembly is requested:

992,487 37-data-disassemble –thread 1 -s 4294967296 -e 4294967388 — 1
992,576 37^done,asm_insns=[{address=”0x00000000″,inst=”\t\t; instruction: 0xffffffff”},{\
address=”0x00000004″,inst=”\t\t; instruction: 0xffffffff”},{address=”0x00000008″,inst=”\\
t\t; instruction: 0xffffffff”},{address=”0x0000000c”,inst=”\t\t; instruction\

And so on… Note that the disassembly address range does not have the application flash offset (0x8000 in our case) applied to it, so that could very well be a bug? It’s also not clear that it’s only a GDB display issue, as manual control of the app using stepi instructions also leads to failure.

If you think this is a P&E problem, I will contact them directly, but my first question is still – how were you even able to debug your non-bootloaded application with a flash offset?

LikeLike

Reply ↓
- Erich Styger on August 19, 2014 at 07:54 said:
  
  If you have loaded an application like that, you must inform GDB about the symbols and where they are loaded. So if you are just debugging the application, but have not loaded the symbols of the bootloader, then gdb will not know anything about the bootloader.
  
  LikeLike
  
  Reply ↓
  - Vishal on August 19, 2014 at 19:40 said:
    
    Hi Erich,
    
    Sorry, I guess I didn’t explain very well. When I say we are debugging, I just mean through KDS with the bug icon button – nothing out of the ordinary. The application seems to be flashed to the offset location that we set up as per the instructions above. The bootloader doesn’t even enter the picture because we haven’t flashed one.
    
    After starting the debug session, we get the dreaded “No source available for 0xFFFFFFFE (0xFFFFFFFE)()” error. And this is for the application that GDB itself loaded but somehow isn’t correlating to the offset flash. I can’t be sure it’s only a correlation problem, because even stepping through the code using GDB “stepi” instructions fails.
    
    My evidence that this may be a bug is that without any Flash offset, we see exactly the same disassembly offsets in the GDB log console:
    
    37-data-disassemble –thread 1 -s 4294967296 -e 4294967388 — 1
    
    Without an offset, the command returns:
    
    36^done,asm_insns=[{address=”0x00000000″,func-name=”__vect_table”,offset=”0″,inst=”strh\tr0,\……..
    
    With an offset, the command returns:
    
    37^done,asm_insns=[{address=”0x00000000″,inst=”\t\t; instruction: 0xffffffff”},{\…..
    
    However, the code definitely has been flashed to the right place and we can see that in the disassembly view…
    
    Anyway, I think I will just forward this to P&E if they are in charge of the Eclipse plugin. I was hoping you ran into the same issue when debugging the application after following the setup above. Do you by any chance have this project in Github?
    
    LikeLike
    
    Reply ↓
Mate Rigo on September 22, 2014 at 16:46 said:

In my build process I just added the bootloader binary to the linker, which links it to the first 8Kbyte of the flash address. The normal user software is offset by 8Kbyte, and behaves normally, after the bootloader jumps to it during debugging.

This way the Jlink Segger I use would actually download it every time, except that it does not, because it checks if an erase is actually necessary.

Vishal: How do you expect your code to run, if you, I quote:
“The bootloader doesn’t even enter the picture because we haven’t flashed one.”

There must be something at the first 2 words of the program flash, that the MCU can start to execute.

LikeLike

Reply ↓
Pingback: Updated P&E GDB Server for Eclipse: Connect/Attach and Advanced Flash Programming | MCU on Eclipse
Geoff S on September 2, 2016 at 13:05 said:

Erich, is there a way to do a similar thing (ie preserve memory ranges) when using a Segger J-Link ?

LikeLike

Reply ↓
- Erich Styger on September 5, 2016 at 15:04 said:
  
  Hi Geoff,
  not that I’m aware of. I had to use that feature in P&E as it does a mass erase of all flash blocks, while the Segger J-Link only does a download to the changed blocks. I believe it might be possible with the J-Link software, but quickly checking the manual I have not found a way. Maybe I have missed it?
  
  LikeLike
  
  Reply ↓
steve on September 15, 2016 at 09:05 said:

Hi,
I have a custom board with KE04Z128VLD4, codewarrior 10.6.4, multilink Universal Fx debugger , set the correct processor in project and debugger, tried also to select manually arp file, but always get the same error.

INF: Initializing.
INF: Error loading .ARP file : C:\Freescale\CW MCU v10.6.4\MCU\bin\plugins\support\ARM\gdi\P&E\ke04z128m4_pflash_pipeline.arp. Set PC and Run Error.
and for the automatically selected arp :

Error loading .ARP file : C:\Freescale\CW MCU v10.6.4\MCU\bin\Plugins\support\arm\gdi\P&E\freescale_ke04z128m4_pflash.arp. Set PC and Run Error.

i can’t see what’s wrong, do you have any idea?
Thank you in advance 🙂

LikeLike

Reply ↓
- Erich Styger on September 15, 2016 at 13:18 said:
  
  Hi Steve,
  I recommend that you use the CodeWarrior for MCU10.7 (or 10.6.4) as they can do the memory preservation in the P&E dialog. This article has been written originally for GDB where at this time this functionality was not present in the GDB version (now it is). So if using CodeWarrior for MCU, you do not need to patch the files.
  I hope this helps,
  Erich
  
  LikeLike
  
  Reply ↓