K22 Baud Rate

[burgeh]

Greetings,

I am using the K22FN256LH12 micro controller on a custom board with KDS v3.2 and Processor Expert.

I am using modem with this chip that requires a 921600 baud rate. My system clock is the internal 20 MHz, and I am wondering if there is a combination that can get me closer to this 921600 baud rate. Currently with 1% error I get 

However, since this is not 921600 I believe it is causing some minor issues with my modem. At times I seem to miss characters.

Any suggestions?

[mjbcswitzerland]

Hi Christopher

The K22's has UARTs and a LPUART.
The UARTs 0 and 1 are clocked from the core/system clock and the other UARTs are clocked from the bus clock
The LPUART can be clocked from various sources (including the 48MHz IRC48M)

Therefore both the accuracy and the resolution that can be achieved depends on the clock source and also the speed that it has.

You say that you have the system clock set to 20MHz internal, which I assume is the 32kHz IRC multiplied by the FLL by 640 (default out of reset) to get 20.9715MHz "nominal".

Assuming you are using a UART from this clock speed directly the best frequency achieved is indeed 911'805 as additionally confirmed by the uTasker simulation below:

If you were to trim the IRC to 33.12kHz (from its nominal 32.768kHz) you would theoretically achieve the desired Baud rate.

Beware however that the IRC has only low accuracy and additional drift over voltage and temperature takes place, you its use as reference for UARTs in real products is rather questionable and could result in potentially major reliability issues in the field.

A better choice for professional products is to use a crystal reference (the RTC crystal will give the same resolution but with much superior accuracy and stability). As a developer of many such products I always use at least the RTC crystal and would carefully exclude liability for IRC usage (if it were still to be demanded in order to save the component).

Also bear in mind that problems with reception at this high rate (and fairly low system clock speed) could be due to interrupt overloading (during data reception you will have a UART Rx interrupt to handle every 11.9us) and if the CPU can't keep up (also due to other interrupts in the system that can't be pre-empted) it could result in loss of characters due to overruns. DMA reception is to be considered since it then removes almost all loading from the CPU and ensures optimal reliability.

Regards

Mark

[burgeh]

Thank you for the information and reply,

There are some inconsistencies I get when I am receiving information from the modem. It seems that the longer the message, the more error is associated with it. I am not sure if it is due to interrupt saturation or because the baud rate is a bit off. Most of the inconsistencies are just a missing character, but that can be quite important in some cases.

[mjbcswitzerland]

Christopher

When you receive each character check also the receiver overrun flag which will show you whether loss it is due to input overrun.

If this is the case, you can increase the CPU speed to see whether throwing more CPU power at it helps or not. You can simply use a different FLL factor (from its default of 640), potentially increasing the flash and bus clock dividers to keep them in spec.
To remove Baud accuracy doubts use a crystal source for comparison tests.

If you find the CPU is overloaded you will need to either increase the CPU speed generally or move to DMA, remembering that any unreliability now could be increased further as your project develops and the CPU has more other things to do too.

Regards

Mark

uTasker - for immediate and complete Kinetis solutions