Hi,
I am trying to develop embedded software for my new design. I used MKE04Z8VTG4 microcontroller in this project. And you can find the schematic of microcontroller's pins below to see the connections. I dont use crystal as a external clock source. I want to use internal reference clock with FLL.
While I was trying to start up the system. I realized that code is stopping somewhere. By trying to set a output pin to high after line by line in code, and observing this output pin, I found the line where program hangs.
I tried two different code to initialize clock source, actually they are almost same. The upper one is from sdk library, the bottom one is taken from "KE04 Sub-Family Reference Manual".
MCUXpresso(MCUXpressoIDE_11.3.0_5222),
SDK(SDK_2.9.0_MKE04Z8xxx4) and
MCUXpresso Config tools(MCUXpresso_Config_Tools_v9_x64) are latest versions.
I realized that, in debug mode everything works good. But If I program the MCU in release mode, it hangs.
In Release mode program cannot pass the FLL lock check line. Has anyone any idea? Thank you,
Okan,
Hi all,
Thanks for @mjbcswitzerland,I have debug this ,but the issue did not occur.
"Now it works but I have problem when I enable "Enable link-time optimization" in c compiler settings."
What is this issue? Will it optimize your code ?
First of all thank you for your answers. @mjbcswitzerland @nxf58904 @ErichStyger. The first problem was as I explained related with NMI pin. Probably by chance or somehow it was always hanging at the FLL lock line. after I insert "SIM->SOPT &= ~SIM_SOPT_NMIE_MASK;" this line at startup, problem is solved. I can repeat same problem when I remove that line.
Since my uController just have 8k flash, I am trying to enable all optimization options. I saw that if I enable -link time optimization(no matter what level of optimization I selected in linker settings), the PIT interrupt does not work. "PIT_CH0_IRQHandler" function is not called.
I saw somewhere that they have said, linker may remove if the attribute weak is defined. Probably linker cannot find the usage of these functions so they are removed. I tried to use "used" attribute but it did not helped.
If you have any suggestion, I can try.
Regards,
Okan,
Hi
1. Since the processor's default is the same as the code is setting you could in fact just remove the code.
2. Changing BDIV can be performed at any time after the configuration since it has nothing to do with the FLL.
3. I don't see any reason why the FLL lock bit would not always be set high since it never had to re-lock (unless it never locked in the first place due to an issue with the power supply). The processor is operating (to run the code), already clocked by the FLL's output clock - even if it is not actually in the "looked" state (if the reference source is missing for some reason and can't be locked to the FLL will tend to still oscillate at its natural frequency - unlike a PLL that will fail)
4. If running in debug mode (maybe no optimisation) but not in release mode (maybe optimised) check that the status register is declared as volatile to be sure it is really being read.
5. Since your start up code is not in fact doing anything (just writing the default register values again) I would either temporarily remove the line that hangs or the complete initialisation (you can still set BDIV, DIV1 and DIV2 is you want slower core/bus/flash clocks but their defaults are also safe) and provisionally continue working with the board. When running you can also do some more analysis of the register states by reading and displaying them to get a feel for whether there is something wrong with the FLL lock flag behavior or performing other experiments also test the loss of lock status to see whether it does lose lock generally - which again would point to an issue with the HW which is only really the power supply that could be externally influenced (whereby there is not a lot to experiment with if the FLL is to be used in its default state anyway).
Regards
Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements
For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/kinetis/FRDM-KE04Z.html
I solved problem. It was related with NMI pin used as MISO. It was working in debug mode, but it was crashing in release mode.
I insert "SIM->SOPT &= ~SIM_SOPT_NMIE_MASK;" this line at the begining of the program. Now it works but I have problem when I enable "Enable link-time optimization" in c compiler settings.
