my code was not retained in flash after power is removed

[danieltruong]

I programmed my code into the KL27Z using KDS3.2.0 and Segger J-Link cable, everything worked fine in debug mode. However, when I removed J-Link connection and power cycled the board, the program did not run. It looks like my program was lost after power was removed. I'm wondering if anybody knows what could possibly the reason?

I used to have the same setup with my previous version of boards and it never failed this way. Now I have the new board with same microcontroller, with a different I/O assignment. I'd appreciate your help very much.

For the record, I'm using the MKL27Z256xxx4.

Thank you.

Daniel

[BlackNight]

What toolchain/IDE/version are you using?

Could it be that you are using a 'RAM' target: then yes, your code will be loaded to RAM and not persistent.

Another thing I saw: are you using printf()/semihosting: depending on the implementation, this only works with a debugger attached and blocks if you are using it without a debugger. I would turn on a LED at the beginning of your main() to see if this is the case.

I hope this helps,

Erich

[danieltruong]

Hi Erich,

Thanks for responding.

I'm using NXP Kinetis Design Studio version 3.2.0 and the Segger J-link probe to program the .elf file in via a 9-pin SWDIO connector. I have been using the same toolchain in the past 2 years without any problem. As for semihosting printf, I followed your article to set up the KDS to use those Segger print statements (SEGGER_RTT_printf, SEGGER_RTT_WriteString).

https://mcuoneclipse.com/2015/07/07/using-segger-real-time-terminal-rtt-with-eclipse/ 

Following your recommendation, I moved a "led turn on" statement before those Segger print statements. The led was never turned on which still indicated that my program was not running after power removal.

Do you know of anyway I can view in the KDS setting that I'm using 'RAM' target instead of flash? And if I can modify the setting to target the flash?

Thanks,

Daniel

[BlackNight]

Hi Daniel,

I wrote a while back an article how to actually debug it in RAM (RAM Target with Kinetis Design Studio and FRDM-K64F | MCU on Eclipse ). Can you debug your application and check if it is executing instructions in RAM area? Use the disassembly view as in above article to verify it.

That way you know if it is indeed running in RAM or in FLASH.

It could be that you selected in your project the 'RAM' build target (if there is one)?

I hope this helps,

Erich

[danieltruong]

Erich,

I read your article in an attempt to debug in RAM. Unfortunately, since I'm using KDS3.2.0 and there is anything in the configuration setup that looks like the menu you showed in Processor Expert. I can't find where I can switch back and forth between RAM and Flash in this version of KDS.

Here are a few snap shots of the Build Configuration setting menu:

However, I found a checked box named "Create flash image". If this is it, then it is checked and the program should be in flash, isn't it right?

Anyway, I found something similar to your "Pre-run reset halt" in the Debug/Launch configuration. It is named as "Pre-run/Restart reset". The box is checked as default. 

I attempted to uncheck it and launched my debug session. I don't see anything different in the log that follows. How do I know if it's running out of RAM or flash? The disassembly view was blank in either case.

In summary, I've got to find a way to set the build configuration to target the flash instead of RAM. And it looks like I got stuck.

By the way, I also tried to download the firmware with KinetisFlashTool through the USB channel via the ROM bootloader. The tool indicated that the image was successfully updated.

However, after a power cycle, the program never started. Could it be loaded in a wrong area of flash that the microcontroller can't retrieve it after it exits the ROM bootloader? 

-Daniel

[ZhangJennie]

Daniel,

Besides Erich's suggestion, another point I can consider of. is there any print to console code  existing in your source? if yes, you may disable it when it is without debugger.

From your screenshot, you use linker file MKL43Z256xx4_flash_ld. I think you should burn code to flash. You can check Flash memory it by "connect to running target". after launch debugger, check memory window. thus you can confirm if there is any code in flash.

Jennie Zhang

[danieltruong]

Hi Jennie,

I removed all the Segger printf statements but the problem still exists.

I attempted to launch the debugger with the box "Connect to running target" checked, as soon as the file is loaded, I couldn't start the program because the Resume button (under Run menu) was de-highlighted. Only Suspend and Terminate buttons are available. And based on the Console log below, it looks like the micro can't read from memory address 0x0000000000. Does that mean there's nothing in flash, is that right?

This behavior is different if I ran without connecting to target. I could control the program from the beginning by pressing the Resume button.

I've never experienced this problem before with my previous versions of boards using same microcontroller and toolchain. To make this new project, all I did was copying the previous project, updating the pin_mux.c file for new I/O assignments. I kept other files the same.

--Daniel

[ZhangJennie]

Hi Daniel,

I would suggest you try same with a new created project.

If you verify the problem is only in specific project, upload your project here. thus I can check it directly.

Have a great day,
Jennie Zhang

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