KE06 using 18.432MHz XTAL not working in FEE

[tedk]

We built a custom board based around the MKE06Z128VLK4, with an external crystal with a nominal frequency of 18.432MHz.  We are using MCUXpresso v10.2.0, and using the built-in Clock-config-tool. When we set up the clock module to have the ICS Mode set to FEE (FLL Engaged External), and tell the tool we're using an 18.432MHz external crystal, the part doesn't run.  If we use the same clock frequency, and set ICS Mode to FBE the part works.

I started experimenting with a FRDM-KE06Z eval board, replaced the 8MHz crystal that comes with the board with an 18.432MHz crystal from same ABM3B crystal family.  When I tell the Clock-config-tool that my crystal frequency is 18.432MHz, the part doesn't run.  When I tell the Clock-config-tool that my crystal frequency is 18.0MHz, the part runs fine.  The only setting I'm changing in the clock-config-tool is the crystal frequency; everything else is staying the same: RDIV=512, BDIV = /2, DIV1 and DIV3 = /1, and DIV2 = /2.

When I tell the tool I'm using 18.0, 18.1, or 18.2MHz it works, but as soon as I get to 18.3MHz, it stops working.  I'm not sure what I'm missing here...changing this one value in such a small amount, without changing any other settings, and without changing the physical hardware, results in the part not running?

To tell if the part is running, I'm simply using the frdmke06z_gpio_1_led_output program to toggle an LED.

Many thanks to anyone who made it to this point in my description.

[tedk]

Thank you Mark and Xiangjun for looking at this!

One of our software engineers (Anthony) figured out the problem.  It turns out that the 18.432MHz clock isn't directly the problem.  Using this frequency with the configuration tool generates the correct register settings and code.  Anthony was able to use that frequency, and single step through the program to find out where it branched to the hard-fault interrupt handler.  It turns out that using an 18.432MHz external crystal in FEE mode, and trying to reach a baud rate of 115,200 on the UART creates a greater-than-3% error in the baud rate; this causes the fault, and this is what I was seeing as the processor "hanging."

Thanks again for the attention!

Ted

[mjbcswitzerland]

Ted

Having a bad Baud rate at a UART will not cause a hard fault (at least not that I have ever heard of or experienced). It will cause corruption of reception data if off, so is there something in the general code that has a problem with handling this? If so, it is wise to fix it since even with a good baud you can't guarantee that such errors won't be encountered in real operation.

Regards

Mark

[tedk]

Hi Mark,

I agree with what you say above.  It seems in this case, though, in starting with an example program, we're using a ton of code provided by NXP (even in this ridiculously simple example to toggle a GPIO).  And, that code either directly or indirectly creates the conditions for a hard fault from the clock/UART settings.

In the example project (gpio_led_output), the 3rd function call in main is:  BOARD_InitDebugConsole();

This, in turn, calls:  DbgConsole_Init()

which calls:  LOG_Init()

which calls:  IO_Init()

which eventually calls:  UART_Init()

inside UART_Init(), which is in the file "fsl_uart.c", it calculates your baud rate error, and if it is greater than 3%, the function immediately returns with a error code.  The return value of that function is not checked, and thus the error code itself is not consequential.  However, because the UART_Init() function returns as soon as it sees that the error is too high, it doesn't complete a bunch of other stuff to setup the UART.

The next function call directly after UART_Init() is UART_EnableTx(), this is in the file "fsl_io.c".  The first thing this function attempts to do is enable the UART by enabling the bit in the C2 register:  "base->C2 |= UART_C2_TE_MASK;"

Single stepping through the program, immediately after this line, you end up in the hard-fault handler.

I haven't dug into what registers are setup in the UART_Init() function AFTER the check on baud-rate error, but apparently the enabling of the transmitter requires one/some of those registers to be set correctly, otherwise you end up with a hard fault.

Thanks!

Ted

[mjbcswitzerland]

Hi Ted

OK - that is a good explanation; the code simply won't allow you to continue of the rate if off.

Regards

Mark

[xiangjun_rong]

Hi, Ted,

If you use 18.432MHz crystal, and the RDIV is 512, the FLL input clock frequency is 18.432MHz/512=36KHz, the FLL input clcok frequency is from 31.25Khz to 39.0625KHz, the FLL output frequency is 36KHz*1280=46MHz, so it is okay.

As Mark points out, pls check the ICS and OSC module register to compare the difference.

Hope it can help you

BR

Xiangjun rong

[mjbcswitzerland]

Hi Ted

I simulated your 18.432MHz crystal and divider settings in the uTasker KE06 simulator and didn't see any problems.

The core clock is 23.04Mhz and bus/flash 11.52MHz (see below)

Since you are not changing any divider values between crystal frequency changes I would suspect the oscillator configuration.

Take a look at the code that is generated in the two case and see which value it sets to OSC_CR. Check that it correctly selects the high range and also that it consistently selects the high gain setting according to your HW needs.

Regards

Mark

uTasker - for more performance and faster, cheaper product development