Hello,
I've a strange problem. On my development board (Freedom K22FN), now I run the exactly same code on my custom board, debugging it over JTAG and the code gets stucked here:
#ifdef SYSTEM_SMC_PMPROT_VALUE
SMC->PMPROT = SYSTEM_SMC_PMPROT_VALUE;
#endif
/* High speed run mode enable */
#if (((SYSTEM_SMC_PMCTRL_VALUE) & SMC_PMCTRL_RUNM_MASK) == (0x03U << SMC_PMCTRL_RUNM_SHIFT))
SMC->PMCTRL = (uint8_t)((SYSTEM_SMC_PMCTRL_VALUE) & (SMC_PMCTRL_RUNM_MASK)); /* Enable HSRUN mode */
while(SMC->PMSTAT != 0x80U) { /* Wait until the system is in HSRUN mode */
}
#endif
The code gets locked in line 8.
What stops a kinetis MCU to enter high speed run mode?
And what could be the possible problem?
-Michael
Okay, Problem was the following: I used the
instead of
and the crash happend.
Do you have an idea why this crashes? Isn't the FX a superset of FN?
Is there a way to also work with the FX?
Hi Michael,
the difference is in flexmemory. FN represents the only 512k P-flash memory, FX represents FlexMemory available on the chip it measn 256k P-flash + 256k D-flash (with EEPROM emulation available). You probably need in your project to select proper MCU (...FX...) to allow flash algorithm flash device correctly + correct likner file to allow placement code/constant into the correct flash block. However, not sure it will be related to the thing you are facing with HSRUN mode.
What I am worried about is that your chip (FX) does not allow HSRUN mode. Please check your mask set number, it is below the part number. if it is 1N41K then I am pretty sure it doesn not icluded HSRUN mode in SMC, only normal RUN. So, if you required to run at 120MHz then no need to enter HSRUN in your case, it is possible to use only normal run more. It can be sometimes misleading for our customer to recognize what exact device they have, especially in a case of K21/K22. Th ebest way how to recognize it is mask set. Hope this will help you.
I guess you silicon is that one:
regards
R.
New discovery. I tried the following code:
SMC->PMPROT = SMC_PMPROT_AHSRUN_MASK; | // Allow highspeed run mode |
SMC->PMCTRL &= ~SMC_PMCTRL_RUNM_MASK; | // Clear the [RUNM] field |
SMC->PMCTRL |= SMC_PMCTRL_RUNM(0x80U); | //Set [RUNM] field |
if( (SMC->PMCTRL &SMC_PMCTRL_RUNM_MASK) == SMC_PMCTRL_RUNM(0x80U)){
if( SMC->PMPROT & SMC_PMPROT_AHSRUN_MASK){
while(3); |
}else{
while(4); |
}
}else{
while(2);
}
And it stops in while(4). So the PMPROT register is not(!) writeable. How can that be?
The datasheet says: "The PMPROT register can be written only once after any system reset."
Yes, above is my first write. But anyhow it does not seem to work.
I believe that your problem might be with the line enabling HSRUN mode. I just tested this code, and it works. Give it a try?
SMC->PMPROT |= SMC_PMPROT_AHSRUN_MASK; // Allow highspeed run mode
SMC->PMCTRL &= ~SMC_PMCTRL_RUNM_MASK; // Clear the [RUNM] field
SMC->PMCTRL |= SMC_PMCTRL_RUNM(HSRUN_MODE); //Set [RUNM] field
while(SMC->PMSTAT != HSRUN_MODE){/* do nothing */} //Wait for HSRUN Mode to be achieved
**Note that HSRUN_MODE is defined as 0x80U, just as you have it.
Also, if you're entering HSRUN_MODE so that you can run at higher clock speeds, make sure that you increase the clock speeds to your desired values only AFTER you have achieved HSRUN mode, not before.
Sorry for my bad english yesterday. But thanks for the support!
I checked the code on the Freedom K22F DevBoards, and there it works without flaws.
I tried your code, on my custom board - same issue.
I changed the MCU, and still the same issue. So I highly assume it's my layout.
So I guess there must be something in my hardware (board) wrong. I attach my schematic of the MCU. To the reset pin i added aditional 100n, just to make sure.
Can you observe an error or tell me what pins could be wrong?
Hi Michael,
I would also check the current consumption on your board (I see couple of pins in your design floating, especially unsued analog pins we recommend to connect to ground).
May be also check whether your code include RTC oscillator configuration as in your design EXTAL/XTAL are floating.
If you have just re-used some sample code from KSDK check also whether the pins (input/output) are configured properly with FRDM boards,
You also using USB regulator with 1uF on USB regulator output which is under our specification (recommendation is 2u2).
regards
R.