Difficulty to debug in SRAM

[mjbcswitzerland]

Hi All

Using KDS, debugging in FLASH is essentially fine.

However when building for SRAM the code is correctly loaded to the SRAM but the debugger is trying to display the start location from FLASH - it loads the SP with the value in Flash at 0x00000000 and sets the initial program counter with the value in Flash at 0x00000004 (rather than from the equivalent information loaded to the SRAM)

Is there some (additional) configuration that is needed so that it can successfully debug in SRAM? With CW10.x, debugging s SRAM hasn't caused problems.

Regards

Mark

[Jorge_Gonzalez]

Hello Mark:

Is this a general issue or only with a specific device?

Also, since KDS does not provide RAM targets, I assume you tweaked some settings such as the linker file. Can you provide detailed steps or a example project?

I would like to give a check to this behavior.

Regards!

Jorge_Gonzalez

[mjbcswitzerland]

Jorge

This is a general issue - I did find that with the KDS Beta version I could debug in SRAM but I had to manipulate the PC value since it was setting it from the Flash content (rather than the entry point) - then I could let the code run and perform usual debug operations.

In the lastest KDS I can't get the code to run in SRAM even after manipulating the PC accordingly - I can't work out why because I have to abort the debugger when I try since it doesn't respond any more.

The K64 target is easy to use since it has such a large SRAM so the FRDM-K64F is best to test with.

I build the uTasker project from here KINETIS Project Code It is very easy to test:

1 - import the project into KDS (read the readme.txt to set the KDS project files rather than the CW10.x project files since both KDS or CW10.x can be used)

2 - select KINETIS_K64 and FRDM_K64F as target in the project configuration file \Applications\uTaskerV1.4\config.h

3 - Select the target "uTaskerV1.4_RAM"

4 - ensure that the compiler is set for m4 (and not m0+)

5 - set the linker script to K_256_RAM.ld if not already set

6 - build the project

7 - load and debug (and see the behaviour)

In case of difficulties with the step-by-step above see the video here: uTasker for Kinetis using CodeWarrior - YouTube - the details are the same for KDS.

The same can be done for most Freedom and Tower processor boards that have enough SRAM by adjusting the 4 settings accordingly. In config.h various features can be enabled or disabled as required (USB, Ethernet, FAT etc.)

Setting the uTaskerV1.4_FLASH target (needs the K_1M_256.ld to be set instead if not already there) allows debugging in Flash, which works as expected.

Regards

Mark

[BlackNight]

Hi Mark,

I admit that I do not see much sense with debugging in RAM ;-), but anyway, I have experimented with it and had it up and running with Kinetis Design Studio V1.1.1. The important point to mention is that for OpenOCD and Segger J-Link you need to disable an option in the launch configuration. Details in RAM Target with Kinetis Design Studio and FRDM-K64F | MCU on Eclipse

Attached is the project I used.

I hope this helps,

Erich

[mjbcswitzerland]

Eric

Note that RAM debugging can be useful in the following circumstance:

- you are using a board for some work and want to quickly test another code. You can load to RAM, test and you still have the application loaded in Flash that you were originally testing. You haven't overwritten anything and so don't need to find and load its source again.

I just updated to KDS1.1.1 since I was using 1.1.0 before.

I also started using the JLINK debugger on the FRDM-K64F. The P&E one doesn't work very well with KDS1.1.1 and it even temporarily bricked by board when loading to SRAM (!?!)

Anyhow your project works fine but mine still won't with the JLINK settings that you use. When I download it simply starts running the code that is already loaded in the Flash, and of course overwriting the downloaded code to RAM in the process. The only way that I can find to work-around this is by setting the initial PC manually as follows:

I have to look up the start address from the MAP file and enter it in HEX (without any leading 0x).
then I can download and it correctly stops at the main() breakpoint and I can then debug normally.

Unfortunately I can't work out why the debugger somehow sets the PC value correctly for your project (???)

Also I have to have code loaded in Flash that sets the SP correctly (this is no big deal though) whereas I see that your project gets around this by setting the SP in code in __thumb_startup() (rather than in the reset vector).

In both cases (my project and your project) it is not possiblöe to command a reset when debugging. I have to quit the debugger and reload each time...

Regards

Mark