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

cancel
Showing results for 
Search instead for 
Did you mean: 

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

1,470 Views
hemant2007
Contributor I

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!!!

0 Kudos
7 Replies

690 Views
hemant2007
Contributor I

thanks all ...

problem is solved now.

0 Kudos

690 Views
rhysdrummond
Contributor III

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.

RD

0 Kudos

690 Views
rhysdrummond
Contributor III

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.

0 Kudos

690 Views
Kan_Li
NXP TechSupport
NXP TechSupport

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

0 Kudos

690 Views
hemant2007
Contributor I

yes MCU still reset

0 Kudos

690 Views
Kan_Li
NXP TechSupport
NXP TechSupport

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

690 Views
hemant2007
Contributor I

Thanks Kan_Li !!!!!

I will try your suggestion.

0 Kudos