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:
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.
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.
Hi Mohammed,
Sorry for the delay reply.
Please check the default watchdog timeout value after reset is approximately 4ms:
Wish it helps.
B.R.
Mike
