Freescale K22 Cortex-M4  cpu : why Core Lock Up state occurs ???

It is quite hard to guess what went wrong.

First, when you write to AIRCR, is the core in privileged or unprivileged state? It will enter HardFault/BusFault if you try to write to AIRCR in unprivileged state.

Secondly, after you triggered a system reset using AIRCR, but default it should read the vector table in address 0x0 for initial MSP value and reset vector. What is in your vector table at address 0x00000000? Does the reset vector (@0x00000004) really point to 0x00005001?

Finally, assumed you have the correct vector table. Could you check if address 0x00005000 contains your firmware? Or if the linker place it somewhere else by mistake?

regards,

Joseph

Thanks for prompt reply Joseph!!!!

You have written

"Could you check if address 0x00005000 contains your firmware? Or if the linker place it somewhere else by mistake?"

ANS: I have observed that when I give Hard reset it jumps from boot loader to firmware (which is at address 0x5000) but at power ON reset only.

and when I try to soft reset using below stated code 

// Disable - WatchDog and disbled IRQ.

  WDT_DISABLE();

  Disable_ALL_IRQ();

  DisableInterrupts;

  // Small delay is required before Soft RESET.

  delay1S();

  // SOFT RESET For K20

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

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

and this lock up state continues to occur until I MUST give POWER ON RESET.

In both types of reset it will check for valid firmware in boot loader and will jump to its address 0x5000.

It jumps to this address only when there is valid POWER ON RESET

But I don't know why, it doesn't go to firmware in SOFT RESTART case???? or else why core lock up occure????

Thanks

Hmm... SYSRESETREQ should be 0x4, not 0x1.

Could you try change the code and see if it fix the problem?

Bit 0 (VECTRESET) reset the processor only, but not the system around it.

If this doesn't solve the problem, it might also worth posting this question on Freescale forum:

https://community.freescale.com/community/kinetis

regards,

Joseph

Thanks Joseph.

I tried using 4

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

but NO improvements, still same results.

These are .h file defines

#define SCB_AIRCR_SYSRESETREQ_SHIFT              2

#define SCB_AIRCR_VECTKEY_MASK                   0xFFFF0000u

#define SCB_AIRCR_SYSRESETREQ(x)                 (((uint32_t)(((uint32_t)(x))<<SCB_AIRCR_SYSRESETREQ_SHIFT))&SCB_AIRCR_SYSRESETREQ_MASK)

I have already posted on freescale communitiy BUT NO REPLY

I don't know why????

but same code works well for K20 processor, and it is not working for k22..........

https://community.freescale.com/message/361246#361246

and

https://community.freescale.com/message/362070#362070

Anyway Thanks a lot Joseph!!!

By the way r u famous author of cortex series books???

Thanks

The connections from the reset request signal (generated by the processor) to the actual reset controller on the chip are designed by Freescale, so we don't have the details and couldn't give you any additional help.

Potentially the Freescale chip might have additional reset control registers in the watchdog or system management blocks that you can use for resetting the system.

A few other suggestions:

- if you are buying the chips from a distributor, you might be able to get support from your distributor.

- there are some resources on debugging fault exceptions on the web:

Keil MDK application note: 209:Using Cortex-M3 and Cortex-M4 Fault Exceptions

Presentation from niallcooling  (Feabhas

http://www.hitex.co.uk/fileadmin/uk-files/pdf/ARM%20Seminar%20Presentations%202013/Feabhas%20Developing%20a%20Generic%20…

https://community.freescale.com/thread/306244

I am sure you can find additional resources on this topic easily.

regards,

Joseph

(I am the author of the books, but not famous )

Following on from Joseph's kind reference, I've also posted about the hard fault handler which might be easier to understand at:

http://blog.feabhas.com/2013/02/setting-up-the-cortex-m34-armv7-m-memory-protection-unit-mpu/