Device with MK22FN1M0VLQ12 resetting loop after working for some time

[Rigolon]

Hi guys,

I have a device that runs on a MK22FN1M0VLQ12.

The thing is that after working for some time it starts to get stuck on a reset loop at startup.
First i thought it was a problem with corrupted flash memory (the application saves logs in the flash). I used a ping-pong strategy to resolve that.
But some devices returned with a similar problem. I tried to debug one of the devices and without setting any breakpoint it always stops at ASerialLDD2_Init or IntFlashLdd1_Erase, both are functions generated by processor expert. Other devices I used memory dump and was able to see that the memory was indeed corrupted so that's why I fixed how I use the FLASH.

Other important note is that some times it happens after some months, other almost after a year. Also i have devices installed over a year and a half that are running ok.

Other thing is that I tried to memory dump (with usbdm) this device, and trying to read the same address, sometimes it reads fine, and sometimes it returns ARM Transation Fault.

Anyone seem anything like that?

[Rigolon]

Thank you for the reply

I will look into it, as the problem is happening at a time that coincides with a memory reading command. Although there's a pin that is setting HIGH when it should not. This pin is initialized as a LOW output.

That being said, is there something that would explain why it was pausing in those function while debugging? Before the reading command the only time ASerialLDD2_Init() is called is within PE_low_level_init().
I am using a PE Micro multilink to debug.

[db16122]

how about the failing rate？If the failing rate is higher than 50%，please share the error log for further analysis.

Meanwhile does your application have requirement to program and erase internal flash very often？

[Celeste_Liu]

Hello @Rigolon ,

Thanks for the additional details. The debugger halting at ASerialLDD2_Init or IntFlashLdd1_Erase without a breakpoint is a strong indicator that a fault (e.g., HardFault or BusFault) is occurring, not that execution is actually reaching those functions normally. A likely cause is corruption in the vector table region of Flash, if the fault handler vectors are corrupted, the MCU may jump to an incorrect address that happens to land near those PE-generated functions.

You can check the HFSR、CFSR、BFAR、MMFAR registers. 

And you can also refer to the way in How to debug a HardFault on an ARM Cortex-M MCU | Interrupt to verify whether it is indeed a Hard Fault.

Hope it helps.

BR

Celeste

[Celeste_Liu]

Hello @Rigolon ,

Thanks for your post.

I think this looks more like a Flash-operation-related fault or Flash-content corruption issue, rather than an issue in ASerialLDD2_Init or IntFlashLdd1_Erase themselves. The RM states that if the MCU reads an FTFE resource while it is being manipulated by an active Flash command, FSTAT[RDCOLERR] is set, and the read data is not guaranteed.

You can refer to AN4835 , it also says:" Interruption of an erase or program command can lead to corruption of the flash contents. Interruptions could include reset, loss of power, or a conflict with code running on processor."  This matches the observation that reading the same address sometimes succeeds and sometimes returns an ARM Transaction Fault : if a Flash region is corrupted or in an indeterminate state, reading it may trigger a bus fault; in similar cases, erasing the affected sector, or mass erase if needed, is used to recover the Flash array. Please refer to Solved: Find corruption on internal Flash MK22FX512VLH12 - NXP Community for more details.

Hope it helps.

BR

Celeste

[Rigolon]

Thank you for the reply

I will look into it, as the problem is happening at a time that coincides with a memory reading command. Although there's a pin that is setting HIGH when it should not. This pin is initialized as a LOW output.

That being said, is there something that would explain why it was pausing in those function while debugging? Before the reading command the only time ASerialLDD2_Init() is called is within PE_low_level_init().
I am using a PE Micro multilink to debug.