KDS: Preserving Memory Ranges

[SpeedLogic]

I am developing on a K64 custom board a bootloader and an application. I have written the bootloader together with a sample application. I did the same already on many ColdFire in the past.

The problem I am facing is that the P&E debug server seems to erase all the flash on the chip while loading the program to debug. This makes things difficult because I want to be able to debug the bootloader without erasing the application or the application without erasing the bootloader.

I am already aware of the method explained in Preserving Memory Ranges on MCU on Eclipse but it requires to modify the programming algorithm file (.arp) for the K64.

But as the algorithm loaded by the P&E debug server is the same (same CPU) when I debug the bootloader or the application so when I need to debug the bootloader I must modify the file to preserve the range of the application and if I successively need to debug the application I have to modify the file again to preserve the range of the bootloader... a bit impratical.

The memory ranges are in different erase sectors on the flash (bootloader: 0 .. 1FFFF / application: 20000 .. FFFFF).

Is it possible to specify to the debug server to only erase a range when loading?

Or alternatively to specify the .arp file to load so to have 2 different files with different ranges preserved for the same CPU?

[ledvinap]

Maybe it would be enough to combine bootloader and application before debugging.

- Linker could be used link binary image of bootloader into application and binary image of application into bootloader.

- objcopy (if you are using gcc toolchain) can insert binary sections into elf file.

- SRecord 1.64 is capable of manipulating image files (it can be used to include checkum/size/... into image. Bootloader can then run application only after verifying it)

[SpeedLogic]

Hi Petr,

I thought about this before and considered that it would work.

But this is inconvenient because I have to build a special image for debugging and a different one as the image to release to the customer.

I still would like to see this problem addressed directly in the toolchain...

Ciao
Andrea

[trytohelp]

Hi Andrea,

What is the interface used ?

P&E multilink or a P&E OpenSDA ?

Have a great day,
Pascal Irrle

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[SpeedLogic]

Hi Pascal,

I am currently using a P&E multilink universal FX.

I ultimately chose to not modify the .arp algorith file.

In my implementation the bootloader takes control of the CPU from the reset vector, does some checks and then launches the application. The application cannot work without the bootloader because it resides in a different memory range and has no control of the reset vector.

To do my debugging I load the bootloader with the KDS debugger and that also wipes out the application, then I reprogram the application using the TFTP server implemented in the bootloader and finally I can debug the two together. Now I know that my bootloader works as expected.

What I am now missing is that when I need to debug the application, this wipes out the bootloader. When I am done debugging I need to reload the bootloader with the debugger and then to reprogram the application to make the board work from the power on.

I would like to know if there is a method to preserve some areas of memory with the P&E debug server in KDS. The desiderata would be something that is saved in the debug configuration so I could have different debug configurations with different areas preserved.

What is not clear to me, as my code for bootloader and application reside in different flash erase sectors, is why it seems that the P&E debug server erases all of the flash instead of only erasing those sectors effectively occupied by the image to load. The latter was exactly what happened with CW 10.6 for the ColdFire where I found that there was no need to specify any range to preserve as the debugger implementation erased only the sectors of the flash effectively present on the image to load.

Ciao

Andrea

[DavidS]

Hi Andrea,

Please review following link to see if it answers your question:

http://mcuoneclipse.com/2014/07/13/preserving-memory-ranges-with-eclipse-and-pe-gdb-server/

Regards,

David

[SpeedLogic]

Hi David,

as I said in my first message:

--8<--

I am already aware of the method explained in Preserving Memory Ranges on MCU on Eclipse but it requires to modify the programming algorithm file (.arp) for the K64.

But as the algorithm loaded by the P&E debug server is the same (same CPU) when I debug the bootloader or the application so when I need to debug the bootloader I must modify the file to preserve the range of the application and if I successively need to debug the application I have to modify the file again to preserve the range of the bootloader... a bit impratical.

--8<--

I am looking for a solution that is saved in the debug configuration so I could have different debug configurations with different areas preserved for the same CPU.

Ciao

Andrea

[DavidS]

Sorry....I was answering several post at same time and excited that I thought I resolved your issue..

Unfortunately I think we have to wait for another release that hopefully will make improvement for this flash features.

Regards,

David

[SpeedLogic]

Hi David,

no problem.

From what you are saying I understand that there is no ideal solution and that the only method known is the one described in Preserving Memory Ranges on MCU on Eclipse.

Let's hope to have some support built-in in a future release.

Ciao

Andrea