Issues with clock_change() function after external boot

[Vladimir_Zitoli]

Dear all,

I am currently working with the MK81 microcontroller on a custom board and have successfully implemented booting from an external QSPI flash (by using physical addresses). The boot process completes correctly, and a simple test application executes as expected, confirming that the QCB configuration is valid.

Following this, I am attempting to implement the clock_change() function as described in the MBOOTQSPIUG.pdf document. My goal is to configure the MCG in PEE mode using an external 12 MHz oscillator as the primary clock source. From this, I aim to generate a 144 MHz output on MCGOUTCLK.

Subsequently, I configure the SIM->CLKDIV1 register to derive a 72 MHz system clock from the 144 MHz MCGOUTCLK. This 72 MHz system clock is then intended to be used as the new source for the QSPI interface clock, applying a divider of 2 to achieve the final 72 MHz QSPI clock frequency.

Unfortunately, the application stucks as soon as I reset the board. I can not debug it, and I noticed just that an hard fault or something similar happens.

I have attached the implementation of the clock_change() function, which reflects the steps outlined above. I would appreciate it if you could review the function and advise whether there might be any issues or overlooked aspects that could affect the QSPI interface or overall system stability.

Thank you in advance for your support.

Best regards,

Vladimir Zitoli

[Celeste_Liu]

Hello @Vladimir_Zitoli ,

Thanks for your question.

I think below line is wrong. The external 12 MHz oscillator should be in high frequency range, so the RANGE bit of MCG_C2 register should be set to 01.

    // Transition from FEI to FBE

    MCG->C2 |= (MCG_C2_RANGE_MASK | MCG_C2_HGO_MASK | MCG_C2_EREFS_MASK);

In addition, according to the MBOOTQSPIUG, the clock switching function should be executed in RAM to avoid QSPI Flash access conflicts. 

If the clock_change() function is stored in the QSPI Flash, switching the QSPI clock will cause a clock source interruption → abnormal instruction reading → hard fault.

Also pay attention to QSPI timing issue. The QSPI clock source is selected via QuadSPI0_SOCCR[QSPISRC]. The division factor of QuadSPI_MCR[SCLKCFG] must ensure that the final clock is ≤ the maximum supported frequency of the Flash. After the clock is switched, the QSPI frequency division needs to be reconfigured to avoid timing violations.

Hope it can help you.

BRs,

Celeste

[Vladimir_Zitoli]

Dear Mrs. Liu,

thank you for your feedback.

As indicated by the reference manual (table 30-3), it seems that the correct value for MCG_C2[RANGE] should be 0b1X (very high frequency range) for a crystal oscillator which oscillates more than 8MHz.

After investigating, I believe the issue is related to the FLL input frequency requirements. According to the Reference Manual, the FLL requires an input frequency in the range of 31.25 kHz to 39.0625 kHz.

With a 12MHz crystal and MCG_C2_RANGE=2 (very high frequency range), the available FRDIV options produce:

1. FRDIV 256 -> 12MHz/256 = 46,8kHz -> Too high
2. FRDIV 512 -> 12MHz/512 = 23,4kHz -> Too low

None of the available dividers can bring the 12MHz reference into the valid FLL range, which appears to prevent the MCG from accepting the external reference, even in FBE mode where the FLL output is bypassed.

Here, my questions:

1. Is my analysis correct? Does the MCG indeed verify FLL input frequency validity even in bypass modes (FBE), preventing the transition with out-of-range frequencies?

2. If confirmed, what are the recommended solutions to achieve PEE mode with a 12MHz crystal? Specifically:

3. Is the 12MHz crystal officially supported for PEE mode operation on this MCU, or should we consider hardware redesign with an 16MHz crystal?

I have verified that:

- The crystal oscillator is running (confirmed via OSCERCLK output)
- Pin configuration is correct (PTA18/PTA19)
- OSC0 registers are properly configured
- The issue persists regardless of power mode (RUN or HSRUN)

I would greatly appreciate your guidance on resolving this issue, as the 12MHz crystal is already designed into our hardware.

Thank you for your support.

Kind regards,

Vladimir Zitoli

[Celeste_Liu]

Hello @Vladimir_Zitoli ,

As indicated by the reference manual (table 30-3), it seems that the correct value for MCG_C2[RANGE] should be 0b1X (very high frequency range) for a crystal oscillator which oscillates more than 8MHz.

->> Yes, you are right. MCG_C2[RANGE] should be 0b1X. Sorry for the previous misunderstanding.

Is my analysis correct? Does the MCG indeed verify FLL input frequency validity even in bypass modes (FBE), preventing the transition with out-of-range frequencies?

->> It does make sense. However,  I don't think the frequency range of the FLL in FBE mode must be between 31.25 kHz and 39.0625 kHz. Please check below.

For the remaining issues, please give me more time to check. I will let you know as soon as I make progress.

BR 

Celeste

[Vladimir_Zitoli]

Dear Mrs. Liu,

thank you for your reply. I am waiting for your update.

In the meanwhile, I am wondering if I can miss the check on the MCG_S[IREFST] register once I changed from FEI mode to FBE mode: in this way, I should be able to go on in the code and switch finally in PEE mode. Do you confirm?

Looking forward to hearing from you soon.

Kind regards,

Vladimir Zitoli

[Celeste_Liu]

Hello @Vladimir_Zitoli ,

Hope this message finds you well. I need to contact the  internal team to support us on this topic. Per our policy, it is required to provide your End Application Name. Alternatively, any project background information would also be acceptable.

Have a nice day.

BRs,

Celeste

[Vladimir_Zitoli]

Dear Mrs. Liu,

The microcontroller in question is being used on a board designed for IoT applications related to smart vending systems.

Over the past few days, I have identified that the root cause of the previously reported issue appears to be related to the configuration of the HGO bit in the MCG_C2 register. Specifically, in the clock_change() function, I initially set the HGO bit to 1 (High-Gain Oscillator mode). However, when I change this setting to 0 (Low-Power mode), the issue no longer occurs.

At this point, I am unable to determine a clear technical explanation for this behavior.

For reference, the oscillator feedback resistor is 1 MΩ, and I have observed the following signals:

1. HGO = 1: Oscillator signal is a 12 MHz periodic waveform with a 3 V peak.

2. HGO = 1: OSCERCLK output is a constant 3.3 V (DC level).

3. HGO = 0: Oscillator signal is a 12 MHz periodic waveform with a 1.2 V peak.

4. HGO = 0: OSCERCLK output is a 12 MHz square wave.

Could you please help me understand this behavior? In particular, are there more specific electrical or performance requirements (not indicated in the datasheet) that the external oscillator must meet in order to operate reliably in High-Gain mode?

Thank you in advance for your support. Looking forward to hearing from you soon.

Kind regards,

Vladimir Zitoli

[Celeste_Liu]

Hello @Vladimir_Zitoli ,

Thanks for your update very much. Please check the suggestion from the internal:
"

Can you provide your schematic for external clock part?

Please refer to the OSC section here:

Additionally, I recommend that you perform basic unit testing, specifically: setting aside QSPI, just create a simple clock test program to check whether the current hardware OSCERCLK outputs normally with HGO=1. First, isolate all code and functions related to QSPI and test the clock separately.

Reference: Capacitors with 16Mhz crystal in NXP Kinetis MK66 at 180Mhz. - NXP Community

Hope it helps. I'm extremely sorry to tell you that the Chinese National Day holiday is approaching. I will start work on October 9. During this period, community response could be delayed. Sorry for any inconvenience caused.

Thank you again for your understanding and support. Wish you a happy Day!

BRs,

Celeste

[Vladimir_Zitoli]

Dear Mrs. Liu,

As requested, I attached the external clock design.

I tried to load a new project and set the gain mode by using the MCUXpresso Config Tool, but I was not able to change it in clock section. The default mode is the "Low Power" one and it is not editable. I try to deepen the problem, but every suggestion is really appreciate from your side.

Kind regards,

Vladimir Zitoli

[Celeste_Liu]

Hello @Vladimir_Zitoli ,

I have sent your schematic to the internal team for further support.
The SDK for K81 is too outdated. You can try the SDK demo for K82. I tested it, and it allows successful modification of the OSC mode using MCUXPresso Config Tools.
After that, refer to the code changes made during the "update code" button and apply those updates to your K81 project.

Hope it helps.

BRs,

Celeste