CORTEX M4 - RESET Pin (Problem)

[dineshVaghela]

My Controller is MK10N512VLQ

when i have done programing and code Restarts

The RESET pin goes like 40us high and 10us low and it is toggling continuoslly. This is observed in number of Microcontrollers.

i have attached waveform i have captured on RESET pin.

and i want to know the reason for that and its remedy.

[marko2]

Sounds like you might have conflict with EZP_CS line.  Check that line is not pulled down when connecting via JTAG.

Just a quess..

- Marko

[dineshVaghela]

hi,

i have checked EZP_CS line it is not a problem.

the real problem is if i do programming next time then my code works as it is.

but this type of reset pin toggling occuring more number of time after programing.so,

Is there any conditing during power on reset  " controller is not gettng started and it will do soft reset if  some condition does not match ?

bcz i know that during RESET Pin Toggling Problem ,if i create bus error condition then my code comes out from that code  working well.

and Thanks Marko for your Reply

Dinesh Vaghela

[dineshVaghela]

Now i Know that RESET Source is

 Reset source: Core Lockup Event Reset

Can anybody Tell me why this EVENT Occured

[wdehaan]

Hello,

I have the same problem. Reset pin is oscillating and I don't know why.

Does anyone have an suggestion on this?

Kind regards

wdehaan

[AlbertK70]

Has anyone find the reason why this event occured : Reset source: Core Lockup Event Reset ?

In my case, it happens every start of the µC without debuging.

TWRK70F120M

[egoodii]

Your vector/stack@0/4, or some very early code pointed thereto (or as mentioned earlier redirected by pin configuration such as EZ_CS), is 'bad' (as in illegal alignment, instructions or accesses), and at this point all the core can do is issue a hard reset to try again -- which cycles if there is no means to 'get better'.

[AlbertK70]

Thank you egoodii for your answer.

Sometimes (rarely), the µC starts and my project works but most of the time the core hard resets. I don't know why but when I am debugging, it works every time.

Do you know how can I find my problem of bad vector / stack or pin configuration or illegal alignment ? I'm using the example of freescale crt0.s and start.c which I adapt to run with µC/OS-III just after init.

The µC resets after the outSRS() freescale function (/* Determine the last cause(s) of reset */ ) and I get on the serial line :

K70-256pin Silicon rev 1.0
Flash parameter version 0.0.8.0
Flash version ID 1.0.18.0ÿ

Core Lockup Event Reset

Do you have any suggestions ?

Thank you in advance for your answer !

[egoodii]

There will be two significant differences when debugging:

Firstly, the tool probably doesn't use the reset vector, but loads startup conditions directly.

Second is 'time' -- the CPU isn't asked to start right away in that mode.  Things to look for:  The Kinetis processor self-reset 'lets go' somewhere before VDD>1.8V.  If you have code attempting to access anything outside the chip that might not be 'ready' at 1.8V, they may give you trouble.  A most significant example would be a clock source.  If your early code expects a stable external clock source from which to generate internal clocks, that source may not be ready until some milliseconds after something over 3V -- and such a clock fault will show up as a core reset event.  You can try an external hardware reset delay, OR just 'spin' right at the very start of your code for 10's of ms -- personally, I spend that first bit of time verifying the CRC of my bootloader code section before going into it, where it starts with the bump to 96MHz.

I am not DIRECTLY familiar with the new K70 line -- my experiences have been with K40/K60 starting from 1.0 silicon.  While the 1.0 silicon for those had some particular 'problems' with power-on-reset, I think we can assume K70 will NOT exhibit those particular errata...

[Pao_portalinks]

Hi, we encountered a POR issue on K60 (PK60DN512ZVLQ10). The K60 seems to be not able to exit the reset hold by POR. If we press the Reset line, K60 can run normally. Is there any solution to resolve this issue? Thanks!!!  

[egoodii]

It is particularly important for POR issues to know the mask code/silicon-rev of the chip.  Each has specific considerations.

[Pao_portalinks]

Hi egoodii, the chip is marked as PK60DN512ZVLQ10, 4N30D & QCTAK1144R. The 4N30D mask is supposed to be free from the POR issue by the FSL's errata. But this issue is happened at all our 30pcs boards. The system runs well after any other reset event such as Reset pin, LVD etc. except POR. Any advise? Thanks a lot.

[egoodii]

We see no startup problems with 4N30D silicon, but then we have added POWERGOOD into the CPU reset to insure holdoff until full VDD stability.  Your description isn't clear -- do you mean the system will only come up if powered-up while holding an external reset, or do you mean any re-reset event after power-up works correctly?  If the latter, I would first have you check the other items earlier in this thread, most notably your clock changeover timing relative to when you have a stable clock source.  Some further description of the 'early events' in your startup code could help as well.

[Pao_portalinks]

The later is the situation we met. We use a 50MHz OSC as an external clock source which it is powered by the same source as MCU P3V3. It takes start up time to output the stable clock around 3ms~7ms. Is it a possible root cause of the unsuccessful boot? We will check the startup code and try to delay the timing to switch clock source from internal to the external one. Thanks!!!

---

egoodii wrote:

We see no startup problems with 4N30D silicon, but then we have added POWERGOOD into the CPU reset to insure holdoff until full VDD stability.  Your description isn't clear -- do you mean the system will only come up if powered-up while holding an external reset, or do you mean any re-reset event after power-up works correctly?  If the latter, I would first have you check the other items earlier in this thread, most notably your clock changeover timing relative to when you have a stable clock source.  Some further description of the 'early events' in your startup code could help as well.

---

[AlbertK70]

Thank you very much egoodii for your help.

I believe I find my problem: it came from the example code of freescale flash_identify() call  at start and I believe it is as you said: a problem of voltage and alimentation which is not ready at start :

Spoiler

void call into void start(void)

{

...

cpu_identify (void)

flash_identify();/* Determine the flash revision */ 

...

}

Spoiler

/********************************************************************/
/*!
* \brief flash Identify
* \return None
*
* This is primarly a reporting function that displays information
* about the specific flash parameters and flash version ID for
* the current device. These parameters are obtained using a special
* flash command call "read resource." The first four bytes returned
* are the flash parameter revision, and the second four bytes are
* the flash version ID.
*/
void flash_identify (void)
{
/* Get the flash parameter version and flash version ID */

/* Write the flash FCCOB registers with the values for a read resource command */
FTFE_FCCOB0 = 0x03;
FTFE_FCCOB1 = 0x00;
FTFE_FCCOB2 = 0x00;
FTFE_FCCOB3 = 0x08;
FTFE_FCCOB4 = 0x01;

/* All required FCCOBx registers are written, so launch the command */
FTFE_FSTAT = FTFE_FSTAT_CCIF_MASK;

/* Wait for the command to complete */
while(!(FTFE_FSTAT & FTFE_FSTAT_CCIF_MASK));

printf("Flash parameter version %d.%d.%d.%d\n",FTFE_FCCOB4,FTFE_FCCOB5,FTFE_FCCOB6,FTFE_FCCOB7);

printf("Flash version ID %d.%d.%d.%d\n",FTFE_FCCOB8,FTFE_FCCOB9,FTFE_FCCOBA,FTFE_FCCOBB);

/* Clear all of the flags in the flash status register */
FTFE_FSTAT = 0xFF;
}

Maybe you will could confirm and maybe found a solution to solve this problem ?

I delete the call of the function flash_identify() and the µC always starts correctly.

Thank you very much again.

[admin]

The flash_identify() function will not work with mask 0M33Z due to errata 2597: FTFL: Flash firmware Version ID field is not supported.  It should be removed from the source code of 0M33Z parts.  

[egoodii]

I have nothing with which to duplicate your findings, so I can't directly confirm.  I will say that having such trouble while accessing on-chip resources 'surprises' me, but being the flash subsystem it isn't entirely unreasonable -- could just be not ready yet, at that voltage, or with the default clocks.

Glad to hear your project is moving along now!