Ciao to everybody,
a ctm is reporting me a strange behavior (that is replicable on FRDM too) on LPUART of MKL27.
They change the baud-rate with just here after code:
void ChangeUartSpeed(uint32_t xData)
SCI_TI_InitConfig0.baudRate = xData;
/* UART clock source is either system or bus clock depending on instance */
uint32_t uartSourceClock = CLOCK_SYS_GetUartFreq(FSL_SCI_TI);
/* Initialize UART baud rate, bit count, parity and stop bit. */
LPUART_Type * base = g_lpuartBase[FSL_SCI_TI];
LPUART_HAL_SetBaudRate(base, uartSourceClock, xData);
The result is a baudrate exactely 3 times less than expected, if the clock is the MCG_IRCLK (internal reference one): set for 115200 to obtain 38400.
The result is a baud-rate half than expected , if the clock is the 48MHz (for the USB): set for 19200 to obtain 38400.
- Remark_1: If the same code is used for the normal UART (not LP), the result is OK.
- Remark_2: If you don't change the default baud-rate, all is OK.
- Remark_3: the issue is replicable on FRDM-KL27; Attached you can find an "example" where:
° to handle the 2 differente baud-rate edit uart_xmad_task.c file (in Source-Interface-UART)
* at line 16 the parameter #define CORR_FACTOR (1) is the correrction to obtain the right Baud-rate.
* at line 54 if you comment the "ChangeUartSpeed" function callng, --> the baud-rate is the one set by Proc.Exp.
I have alredy checked the ERRATA but there was nothing that can explain it.
...may be an SDK issue ?
The questions are:
Do you know it ?
...is HW or SW ?
do you have any workaround ?
The ctm is not so afraid of it ,because they found a way to solve....BUT of course they prefer to work with no "strange" workaround not coming from NXP.
Any suggestion is more than welcome.
Thanks a lot in advance
Original Attachment has been moved to: x-MAD-TI_FRDM-KL27z.zip