Unexpected behaviour of UART in K22 when baud rate is changed

[vaibhavi_padwal]

Hi,

I am using custom board with MK22FX512AVLQ12. I am using UART of the controller with baud rate set as 19200 and Parity Even. I am using an external application to send and receive data from UART. The parity is set to Even at the external aplication side.

I am performing the following sequence of operation:

1. Send data frame at 19200 : Uart replies correctly as expected

2. In the external application, Change the baud rate to some other value (e.g. 57600) and send data to UART : UART       sends no reponse (as expected)

3. In the external application, Change the baud rate to 19200 (corret baud rate) again, and send data to UART : UART       sends no reponse, which is not expected since the baud rates are matched now.

4. Now if I restart the controller through software and then send the data at 19200: the UART sends the resopnse as       expected.

I have same obervation on FRDM K22 Evaluation board.

I am unable to understand the reason behind such behaviour. Please help in understanding the reason behind this.

Also please suggest a way by which software restart would not be reqiured in above operations.

Thanks and Regards,

Vaibhavi 

[Sabina_Bruce]

Hello,

In addition I recommend to download our SDK for the FRDM-K22 and work with the uart examples as shown below:

You are able to use these as a reference for the configuration of the UART.

Best Regards,

Sabina

[vaibhavi_padwal]

Hi,

Sorry for late reply.

Previously in my interrupt handler I was handling only two status :

1. Rx_IDLE

2. TX_IDLE

I am assuming that the probelm was that somehow all of the UART receiving interrupts were getting disabled when application baud rate or parity was changed.

When I modified the interrupt handler to following:
switch (status)
{
case kStatus_UART_TxIdle:
UART_TransferReceiveNonBlocking(UART_RS485, &g_uart_rs485_handle, &g_p_receivepointer_RS485, NULL);
break;

case kStatus_UART_RxIdle:
g_ui8_dataReceived_RS485 = g_ui8_rxBuff_RS485;
uartByteReceived(g_ui8_dataReceived_RS485);
g_ui8_dataReceived_RS485 = 0;
UART_TransferReceiveNonBlocking(UART_RS485, &g_uart_rs485_handle, &g_p_receivepointer_RS485, NULL);
break;

case kStatus_UART_IdleLineDetected:
break;

case kStatus_UART_RxHardwareOverrun:
break;

default:

UART_TransferReceiveNonBlocking(UART_RS485, &g_uart_rs485_handle, &g_p_receivepointer_RS485, NULL);
break;
}

This switch basically reenables all the interrupts in the default case. With this, the controller need not to be restarted after changing the Baudrate or Parity in Application.

But I have still not found out how and why the all the receiver interrupts are getting disabled when Parity or baud rate of the polling application is changed. Please help in understanding this case espcially for MK22 series controllers.

kerryzhou‌ gauravmore‌

Thanks and Regards,

Vaibhavi

[gauravmore]

kerryzhou‌ 

Hi kerry, 

We are working on this issue since long time. After evaluating it on both evaluation board and our development board we found the same issue.

After analizing the issue we found that after changing the baudrate of the application side it is some how UART receiving interrupts were getting disabled , due to which we are not  able to recieve any data from the application.

As you can see we have done the work around solution as mentioned below

switch (status)
{
case kStatus_UART_TxIdle:
UART_TransferReceiveNonBlocking(UART_RS485, &g_uart_rs485_handle, &g_p_receivepointer_RS485, NULL);
break;

case kStatus_UART_RxIdle:
g_ui8_dataReceived_RS485 = g_ui8_rxBuff_RS485;
uartByteReceived(g_ui8_dataReceived_RS485);
g_ui8_dataReceived_RS485 = 0;
UART_TransferReceiveNonBlocking(UART_RS485, &g_uart_rs485_handle, &g_p_receivepointer_RS485, NULL);
break;

case kStatus_UART_IdleLineDetected:
break;

case kStatus_UART_RxHardwareOverrun:
break;

default:

UART_TransferReceiveNonBlocking(UART_RS485, &g_uart_rs485_handle, &g_p_receivepointer_RS485, NULL);
break;
}

Here we reenable all the interrupts in the default case. With this, the controller need not to be restarted after changing the Baudrate or Parity in Application.

We tried the solutions provided by hte other members but still not able to resolve this issue.

Please let us know whether this is the only way to take care of this solution? Also i think you can also regenerate the same issue are your end by using evaluation board  FRDM K22.  The conditions are given i the initial query  it self by vaibhavi.

Request you to please confirm and let us know the reason or  any modification which is required in order to resolve this issue or the work around solution.

Waiting for your reply.

Thanks 

Gaurav More

[mjbcswitzerland]

Hi

Make sure that your UART driver handles Rx errors correctly (parity, bad stop bit level, etc.), which involves clearing the error itself. If such errors are not cleared the UART Rx will not receive anything else until it is correctly done.

Regards

Mark

[uTasker project developer for Kinetis and i.MX RT]

[vaibhavi_padwal]

Hi,

sabinabruce‌ @mark Butcher

Thank you for your quick and valuable inputs.

I have tried to keep the baud rate the same on both application and microcontroller side and parity mismatched. Then also I am facing similar issue. Controller doesn't reply when parity is changed to correct one on application unless it is restarted using software restart. As per my understanding the parity error flag is cleared by the controller itself ( in the IRQ handler) and there is no need to handle parity error separately in the callback.

I have referred the uart configurations in the sdk example for non blocking transfer and have a similar implementation in my code.

There's is one more doubt I have:

In the driver files I am able to see two different interrupt status

1. Idle line interrupt

2. Rx idle interrupt 

I am not able to understand the difference between the two. Which interrupt will I get if the required number of bytes are received by the Uart?

Please help in resolving the issue.

Thanks and Best regards,

Vaibhavi

[Sabina_Bruce]

Hello,

This post does a really nice job of explaining the difference and what you can expect. 

https://community.nxp.com/thread/301031 

You may or may not be using DMA, but the general idea is explained. 

Please let me know if this helps you or not. Or if you have further questions.

Best Regards,

Sabina