I'm using KDS with a K64. My program uses an area at the end of RAM to store a command line memory, outside of the range that the program initializes on startup, so that its contents survive a reset. If I click "Reset target and restart debugging" in the IDE, the RAM isn't cleared. However, loading new code into the flash wipes it. This used to work with Codewarrior.
My other thread about preserving a flash area led me to this:
Preserving Memory Ranges with Eclipse and P&E GDB Server | MCU on Eclipse
which details how to hack the .arp file that controls how the debugger loads the flash. I looked in these files to see if there was anything that looked like it was telling it to clear RAM, but saw nothing. The debug console doesn't show any commands that look like they do that, either.
The only other difference between my current KDS project and my old Codewarrior project was that I'm now using a FRDM-K64F board and before I was using a TWR-K70F120M or our own K60 board. Is it possible that the reload sequence powers the K64 down completely, thus nuking the RAM, but the TWR board doesn't? I'm using JTAG for programming and debugging, rather than the OpenSDA interface via the auxiliary processor, so I wouldn't think the chip would be power-cycled..
Solved! Go to Solution.
I had a similar problem here: http://mcuoneclipse.com/2014/04/19/gnu-linker-can-you-not-initialize-my-variable/
Erich
Hi Paul,
I suspect it is just a different methodology for KDS as compared to CW10.
I tested FRDM-K64F120M Freedom board using KDS (and OpenSDA) and found that RAM is retained but the last 0x1000 bytes of RAM were used by KDS when a new project flashed.
The end of RAM is also where KDS places the stack so you have to be careful not to use that space.
I haven't tried this using JTAG yet as fyi.
Regards,
David
It turns out it was something else. The JTAG interface doesn't use that portion of the memory while loading code. However, I had declared my command line memory
char linemem[1024] __attribute((section(".uninit")));
and the compiler insisted upon putting zeroes into the object file, even though it's supposedly uninitialized. This seems to contradict the GCC manual, but it's not clear. In my previous project, I had just assigned an arbitrary address in the linker script, rather than defining an actual array in C. I went back to doing that, and now all is fine.
Thanks for your input.
I had a similar problem here: http://mcuoneclipse.com/2014/04/19/gnu-linker-can-you-not-initialize-my-variable/
Erich
The NOLOAD attribute in the linker script! I should have guessed that there was such a thing. That's an even better solution. Thanks.