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