KE/KEA POR Sequence and ICS Module Investigation

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

KE/KEA POR Sequence and ICS Module Investigation

No ratings

KE/KEA POR Sequence and ICS Module Investigation

The 5V Kinetis E series MCUs are designed to maintain high robustness for complex electrical noise environments and high-reliability applications. Kinetis EA series MCUs using the same architecture with automotive level operation temperature range, are various used for auto body electrical application. There was a reality customer requirement to let KEA core running the application (light a LED) within 20ms from power up. It need to know the whole startup processing for KE/KEA product. Please check below picture to get more info about boot sequence:

1.png

During the power up phase, after VDD rising to VPOR voltage threshold, there with about 15us delay before internal IRC start oscillating. T2 interval is FLL acquisition time to make FLL generating clock. The Reset_b pin is released and then the system is released from reset. After that, the NVM starts internal initialization. Flash Controller is released from reset and begins initialization operations while the core is still halted before the flash initialization completes. When the flash Initialization completes (16 μs) , the core sets up the stack, program counter (PC), and link register (LR). The processor reads the start SP (SP_main) from vector-table offset 0. The core reads the start PC from vector-table offset 4. LR is set to 0xFFFF_FFFF. The CPU begin to execute the first instruction. Overview the whole power up processing, FLL acquisition time is the longest time interval almost 1ms, then following power up time about 0.1ms (using 17KV/sec VDD ramp-up slew rate).

There seems a lot of time left to run the chip initialization code and application code. Customer requirement (power up to light a led within 20ms) should be matched without any problem. While, during customer test, there seems it need to take more than 30ms to find the LED be lighten after power up. In order to check the issue, we get the customer test code and find there with below clock initialization code:

void Clk_Init()

{

                ICS_C1|=ICS_C1_IRCLKEN_MASK; /* Enable the internal reference clock*/

                ICS_C3= 0x90;                                    /* Reference clock frequency = 31.25 KHz*/      

                while(!(ICS_S & ICS_S_LOCK_MASK));  /* Wait for FLL lock, now running at 40 MHz (1280 * 31.25Khz) */                               

               ICS_C2|=ICS_C2_BDIV(1)  ;                    /*BDIV=2, Bus clock = 20 MHz*/

                ICS_S |= ICS_S_LOCK_MASK ;              /* Clear Loss of lock sticky bit */     

}

We do a test to check the Clk_init() function execution time and find it will take almost 25ms. We toggle a GPIO pin and almost 25ms for checking ICS status register [LOCK] be asserted. KE/KEA product using ICS module as clock source, which default mode is FEI. In general, during the chip initialization, using ICS status register [LOCK] bit to check if the FLL cock is stable or not. From KE/KEA product datasheet, the Max. FLL acquisition time is 2ms.

2.png

Why the ICS_S[LOCK] bit be asserted need take more than 25ms?

After double check with ICS IP owner, we get below info:

  • The FLL_S[LOCK] bit act as “LOCK detection”, the LOCK bit will be set if FLL clock frequency stays within the tolerance 6% for 20ms~30ms.
  • After acquisition time (max. 2ms) FLL achieved clock accuracy as same as LOCK bit be asserted.
  • After ICS configuration modified, customer can call a 2ms delay routine to make sure FLL acquisition clock successfully before executing the application code. 
Tags (4)
Comments

Hello Hui Ma,

Thank you for this usefull article.

That mean, i can just initialize the ICS Clock without waiting on the LOCK bit, and after the initialization routine just waiting for ca. 2ms? see code below:

void Clk_Init()

{

        ICS_C1|=ICS_C1_IRCLKEN_MASK;  /* Enable the internal reference clock*/

        ICS_C3= 0x90;                                    /* Reference clock frequency = 31.25 KHz*/      

        ICS_C2|=ICS_C2_BDIV(1)  ;                    /*BDIV=2, Bus clock = 20 MHz*/

        ICS_S |= ICS_S_LOCK_MASK ;              /* Clear Loss of lock sticky bit */     

}

__delay_ms(2); // wait for 2ms until FLL is stabil

Am I right?

Thank you in advice.

Hani

Hi Hani,

That's quite right.

best regards,

Hui

Hello Hui,

I have read this article two years ago and followed your advise regarding doing delay 2ms before continuing in the software.

Actually, I have set a delay 5ms instead of 2ms to guarantee the acquisition and it was working good so far. thank you for that.

Now, I just got different results showing that even the 5ms is not enough for acquisition and clock stabilization for the startup sequence, let me show you my example in pseudo code;

Startup sequence:

1- WDOG configuration using the default clock source (No interest in this part) => 40ms

2- Clock and PLL configuration.

3- Delay 5 ms

4- Watchdog reconfiguration to 15ms

5- Trigger watchdog for example 5 cycles

6- Stop triggering watchdog completely

Expected: Reset should occur after 15ms from last WDOG trigger.

Obtained: Reset was happened after 40ms (First configuration of WDOG) showing that the reconfiguration of WDOG was not performed properly

Note that: (Here is the added value) following the same previous example but with very slight change as follows;

1- WDOG configuration using the default clock source (No interest in this part) => 40ms

2- Clock and PLL configuration.

3- Delay 7 ms

4- Watchdog reconfiguration to 15ms

5- Trigger watchdog for example 5 cycles

6- Stop triggering watchdog completely

Expected: Reset should occur after 15ms from last WDOG trigger.

Obtained: Reset was happened after 15ms as expected in a consistent way (I.e. successive resets with time difference from last trigger to reset = 15ms).

Conclusion:

This quiet ensures that the delay after the PLL configuration has a great impact on the watchdog reconfiguration mechanism using the unlocking mechanism.

Would you confirm or clarify this behavior physically please ?

I mainly concluded that the watchdog reconfiguration requires quite more delay after PLL configuration to be set with the new required timeout.

So my question is mainly focusing on confirming this behavior from your side please.

Thank you in advance.

After further investigation, after checking the actual stabilization once the PLL is configured after power on and after internal watchdog reset.

I found out that actual acquisition (stabilization) for the case after power on equals 2 ms as mentioned before, and for the case internal watchdog reset, it is only 1 ms.

This proves that the acquisition is performed properly and delay 5 ms mentioned in the above example should be enough.

So why the internal watchdog reconfiguration is not performed properly !! So strange!.

Could you help please ?

Thank you in advance.

I will change the delay to be 7ms before the watchdog reconfiguration, it is good to say that startup time will be still within the acceptable range.

But I am so eager to know why changing from 5ms to 7ms while acquisition is already acquired after only 2ms.

It seems that PLL delay time has no relation so what kind of factors can affect the internal watchdog reconfiguration ?

Hi Mohammed,

Sorry for the delay reply.

Please check the default watchdog timeout  value after reset is approximately 4ms:

pastedImage_1.png

Wish it helps.

B.R.

Mike

Hi Hui,

Thanks for your reply.

So what is the relation between:

1- The (default timeout value after reset 4 ms) 

2- Delay from PLL configuration to watchdog reconfiguration increases from 5 ms to 7 ms caused successful watchdog reconfiguration while PLL is already stabilized after 2 ms only.

Also I believe that this timeout value 4 ms is default after reset but our discussion here is about watchdog reconfiguration.

Which implies that I already configured watchdog at step 1 in the example overwriting the default one.

Thank you for your support.

Hi Mohammed,

Could you provide your test code? We could try to regenerate your mentioned issue.

best regards,

Mike

Version history
Last update:
‎06-21-2016 02:05 AM
Updated by: