Debug works but not running standalone

[il_andil]

Hi,

I'm using microcontroller MKL02Z32CAF4 installed on a custom PCB and i program it with MCUExpresso IDE version 11.5; I use MCU-Link debug probe with v 3.133 firmware; my SKD is SDK_2.x_FRDM-KL02Z, but I also used SDK_2.x_MKL02Z32xxx4 and the result is the same.

When I flash the MCU (using SWD) with entering the debug mode, I can step through the code, continue the execution and I see with an oscilloscope a pin on a PCB toggling in an infinite loop (that is all the code is doing).

However, when I flash using GUI Flash Tool (or I just power of and then on after debugging session), then nothing happens - it seems like the code isn't running.

I've read a few posts in this forum and didn't find an answer that worked.

Here are a bit more details: I do mass erase, and do SOFT reset handling, and a reset on connection and on completion.

Please help - is there any settings I can check? Does the IDE do something magical in the debug mode that makes the code run, but just flashing it won't work.

[JKPAPER_DELOPT_SR]

Hello, I am facing a similar issue with MIMXRT1064 custom board. But above mentioned options are not avaliable in the startup file. Please help

[ErichStyger]

Hi @il_andil ,

a) are you using semihosting in your code? If so, if your hardfault handler does not deal with it without debugger, then it might block the target. See https://mcuoneclipse.com/2023/03/09/using-semihosting-the-direct-way/

b) Do you use anything from the cycle counter register? It is initialized by default by the debugger, but if you are using it from your application, then DWT needs to be initialized by the application: https://mcuoneclipse.com/2017/01/30/cycle-counting-on-arm-cortex-m-with-dwt/

c) If your device has an EzPort, make sure it is not entering the loader mode, check https://mcuoneclipse.com/2016/12/22/disabling-ezport-on-nxp-kinetis-to-solve-power-on-issues/ 

d) Attach to the running (well, blocked) target with the debugger to see what is going on: https://mcuoneclipse.com/2021/04/25/attach-with-the-debugger-to-a-running-target/ 

I hope this helps,

Erich

[il_andil]

@ErichStyger
a) semihosting is disabled.
I will check your links on (b), (c), (d)
/Andrii

[xiangjun_rong]

Hi,

From hardware perspective, you have to write the application code to internal flash instead of RAM, secondly, pls check the PTA5(Reset_b) pin, the Reset pin must be driven High or float(),there is internal pull-up resistor for the pinPTA5, so it is high if the pin is float.

Hope it can give you a clue.

BR

XiangJun Rong

[il_andil]

@xiangjun_rong

The reset_b pin is floating. The issue is that in standalone mode I see on an oscilloscope that reset_b goes LOW for 30us. 

I think I do write the code into the internal flash.

[xiangjun_rong]

Hi,

From software perspective, Erich has given you a lot of suggestion.

From hardware perspective, pls check the PTB5(NMI_b) pin logic, you'd better configure it high by connecting a 10K ohm pull-up resistor so that the NMI interrupt can not happen. Or clear the FTFA_FOPT[NMI_DIS] bit in the application code.

Pls have a check

BR

XiangJun Rong

[il_andil]

@xiangjun_rong 

The NMI_b pin is driven to the GND on the custom PCB I use. Do you think this could explain why I see resets?

Could you guide me on how to clear  FTFA_FOPT[NMI_DIS] bit from the application code?

/Andrii

[xiangjun_rong · Accepted solution]

Hi,

Pls try to set the flash configuration field with:

__attribute__ ((used,section(".FlashConfig"))) const struct {

unsigned int word1;

unsigned int word2;

unsigned int word3;

unsigned int word4;

} Flash_Config = {0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFBFE};

The FTFA_FOPT[NMI_DIS] bit will be cleared

Hope it can help you

BR

XiangJun Rong

[il_andil]

@xiangjun_rong this did the trick. Thanks a lot!