Kinetis MicrocontrollersのトピックRe: K22 MCU goes into CORE LOCK UP state when try to SOFT RESET

K22 MCU goes into CORE LOCK UP state when try to SOFT RESET

hemant2007 — Tue, 12 Nov 2013 08:53:17 GMT

Hi to all,

I am using Cortex m4 processor from freescale K22,

In boot loader i download my firmware and after that I do following steps to soft restart the k22.

// Disable - WatchDog and disbled IRQ.

WDT_DISABLE();

Disable_ALL_IRQ();

DisableInterrupts;

// Small delay is required before Soft RESET.

delay1S();

// SOFT RESET For K20 ???? is it right for k22 based mcu?????

SCB_AIRCR = SCB_AIRCR_VECTKEY(0x05FA) | SCB_AIRCR_SYSRESETREQ(1) ;

while(1);

Now when MCU gets soft restart signal, next time it goes into CORE LOCK UP state

Ref:

ARM Information Center

Then it remains in Hard fault mode until i give power on reset then this hard fault state never occurs.

Can any body tell why this Hard fault state occurs when I soft restart?????? Also above code works well for k20 based MCU but then why not for K22 ?????

I have created same thread on ARM.com

http://community.arm.com/message/14623#14623

Thanks in advance!!!

Re: K22 MCU goes into CORE LOCK UP state when try to SOFT RESET

Kan_Li — Wed, 20 Nov 2013 09:06:49 GMT

Hi,

I looked into your thread on ARM community, and found you said"

I tried using 4

SCB_AIRCR = SCB_AIRCR_VECTKEY(0x05FA) | SCB_AIRCR_SYSRESETREQ(4) ;

but NO improvements, still same results.

but in above case, 0 written to SYSRESETREQ bit, no system reset should occur, did the MCU still reset and hard fault exception happened anyway? Please kindly help to confirm. Thanks for your patience!!

B.R

Kan

Re: K22 MCU goes into CORE LOCK UP state when try to SOFT RESET

hemant2007 — Mon, 25 Nov 2013 13:04:45 GMT

yes MCU still reset

Re: K22 MCU goes into CORE LOCK UP state when try to SOFT RESET

Kan_Li — Tue, 26 Nov 2013 09:53:50 GMT

Hi ，

Our AE team has tried your code, everything is ok. but we didn't use the same code, because we don't have the macro definition, so we use the following code instead:

SCB_AIRCR = 0x05FA0004;

it works well as expected.

so we suspected if your application code also contains other codes for peripheral initialization. as I know , the above instruction is just used to reset the core, not all the peripherals. so if there is code used to init the peripherals that not reset after this instruction execution, that might cause problem like you met.

Please only try the above instruction to see if the problem is still there.

Thanks for your patience!!

B.R

Kan

Re: K22 MCU goes into CORE LOCK UP state when try to SOFT RESET

hemant2007 — Fri, 29 Nov 2013 04:06:36 GMT

Thanks Kan_Li !!!!!

I will try your suggestion.

Re: K22 MCU goes into CORE LOCK UP state when try to SOFT RESET

hemant2007 — Thu, 17 Jul 2014 04:34:29 GMT

thanks all ...

problem is solved now.

Re: K22 MCU goes into CORE LOCK UP state when try to SOFT RESET

rhysdrummond — Thu, 07 May 2020 05:39:53 GMT

Hi hemant2007- thanks for posting this. I'm up against a similar problem by the looks of things; works fine with K21 but bad with K22. Can you please post the details of what you found? I'm really scratching my head over this.

I know it's been a long time and this is really digging deep into the memory archives.

Many thanks in advance.

Re: K22 MCU goes into CORE LOCK UP state when try to SOFT RESET

rhysdrummond — Fri, 08 May 2020 03:19:46 GMT

I have resolved the issue in my case. It was quite a challenge to find!

In our system we use FlexNVM for "Eeprom". It works fine on power-up, and when starting the application.

But for some reason, when jumping to the bootloader from a SW reset call (as per the above SCB_AIRCR = 0x05FA0004; line) it would BusFault; the Precise error was an address in EE of the first access - a EE read.

It turns out that the EEE state machine starts by copying data from flash to RAM, and for some reason this wasn't happening before the first access was invoked, hence the requested address was not available (therefore Bus Fault).

The actual fix was to add a EE Ready Check before every EE write AND read function:

while(!(FTFE_FCNFG & FTFE_FCNFG_EEERDY_MASK));

(This check was formerly done after each EE write only, so left things open to a race condition).

Helpful information found here: https://www.nxp.com/docs/en/application-note/AN4282.pdf

I hope this helps someone. Cheers.