Internal Clock problem when switching from MKW21 to MKW22 MCU

[matthieuremacle]

Hello,

Until now, I used MKW21D512VHA5 MCU for communication on 802.15.4 protocol. It works great. For supply reasons, I now have to use MKW22D512VHA5 MCU, which is basically the same but has a USB peripheral (that I won't use). Both processors are pin-compatible.

My problem is that since I switched from one processor to the other, I observe a massive difference in the frequency of the clock used as system clock (the clock frequency is 50% smaller with the MKW22 processor). This clock is generated from the low internal reference clock (low IRCLK).

The problem is that I can't communicate by UART anymore because of this behavior.

For both processors, the source code is exactly the same, the only difference is the SDK library that I built with MCUXpresso online tool. 

Here is a screen shot of my clock configuration (exactly the same configuration for both processors :

What are the difference between both processors ? Should I disable something linked with the USB peripheral in order to fix my bug ? 

Thank you for your help,

Best regards,

Matthieu.

[matthieuremacle]

Hello, 

Thank you for this answer. Since I posted it, I have more elements in hand.

The reason my internal clock has not the expected value is because of SCTRIM register. This register contains a trim value adapting the internal clock regarding its actual value. This register is loaded at boot with a value determined during factory production.

On the MKW21 MCU, this register is initialized as expected and contains a typical value of 0x80 (varying from one processor to an other).

On the MKW22 MCU, this register is not initialized and contains 0xFF on every processor, causing the clock drift.

So the question evolved and is now: "Why is this register not initialized on the MKW22 ?" Everything else works exactly the same...

Best regards,

Matthieu.

[gerardo_rodriguez]

Hello Matthieu,

It appears that the MKW22D part was not factory trimmed and the SCTRIM contains the default value of 0xFF. Sorry for the inconvenience this may have caused. 

To solve this, you can use the Auto Trim feature of the MCG module described in chapter 31.4.7 MCG Auto TRIM (ATM) of the reference manual. Basically, this feature uses an external clock reference to automatically trim the internal clocks. The fsl_clock KSDK driver enables this feature with the CLOCK_TrimInternalRefClk() function. To use this feature, the MCG must be configured with an external clock and the bus clock must be in the range of 8-16 MHz.

By default, the connectivity demo applications are configured to use the external clock and run at 48MHz, so it should be easy to use the auto trim feature. What demo application are you using as base? So I can help you setting an example of the auto trim feature.

Regards,

[matthieuremacle]

Hi,

Thank you for your help. The problem is that I have big problems configuring the external clock as well. If I could have a steady external clock, I would not care using the internal one...

I posted a second thread to explain my problem of configuring the external clock (https://community.nxp.com/thread/465055 ) and I can't use autotrim unless I'm able to solve this problem (If I understood correctly this feature).

I now know that I don't have other choice than resolving the other issue first.

Best regards,

Matthieu.

[gerardo_rodriguez]

Hello Matthieu,

I see that your clock configuration is generating an error. Can you share what is the error that you are getting? The source code will not be generated if there are errors. 

The USB module shouldn't interfere with the system clock frequency. Please try enabling the TRACE_CLKOUT and confirm with an oscilloscope that you are getting the expected core/system clock on both of your designs. Please note that the trace clock frequency observed at the TRACE_CLKOUT pin will be half that of the selected clock source. In my case I have the core clock at 48MHz and I'm seeing 24Mhz on an oscilloscope.

You can enable the trace clock with the MCUXpresso clock tool:

Also make sure to change the PTE0 pin muxing to the TRACE_CLKOUT:

 PORT_SetPinMux(PORTE, PIN0_IDX, kPORT_MuxAlt5);            /* PORTE0 (pin 15) is configured as TRACE_CLKOUT */

Let me know your findings.

Regards,