UART crash when incompatible baud rate is set

[MosheH]

Hi,

I am connecting the nRF52832 UART (on my nRF52 DK) to an external device, which by default uses 9600 baud rate (but can be reconfigured differently).

In the case that the UART on the nRF is configured to 115200, and once the first character is sent from the external device (that uses 9600), the application on the nRF crashes, that is, the app_error_fault_handler() is being called.  The error is generated by the uart_event_handler() function, using the APP_UART_COMMUNICATION_ERROR type.

Please note that in case the nRF UART is configured to 9600, all is working OK.

Surely, when there is a mismatch in baud rates of the two ends, I don't expect to get any valid data, yet, I also do not expect the system to crash.

I will appreciate any advise on that problem.

Thanks

Moshe

[Edvin]

Hello,

If you don't want the application to stop on the APP_UART_COMMUNICATION_ERROR you must remove the APP_ERROR_HANDLER(p_event->data.error_communication); inside the APP_UART_COMMUNICATION_ERROR event.

 

Best regards,

Edvin

[MosheH]

Hi Edvin,

What is causing this error in the first place? Usually, mismatch in baud rates just corrupts the data and not resulting in such error.

Thanks

Moshe

[Edvin]

Hello Moshe,

Depends on the error. You can try to debug and find the value of the p_event->data.error_communication. This value should be the value in the ERRORSRC for the UART peripheral. You can see what the different bits mean here.

 

BR,

Edvin

[MosheH]

Hi Edvin,

The error_communication value refers to the framing error.

C

RW

FRAMING

Framing error occurred A valid stop bit is not detected on the serial data input after all bits in a character have been received.

I guess this is due to the baud rate mismatch.

The actual problem I am facing in my application is that the device I am working with uses a 9600 as default and I need to configure it to 115200 (by sending it a configuration message over the link). So, once it was set to 115200, I reconfigure my UART to 115200 and start exchanging messages with it. Yet, in case for some reason this device is reset and go back to its default 9600, I have no way to know that the baud rate was changed and thus puts me in the position where I am still using 115200 and the device is using 9600, which then leads to the crash.

Thus, I would expect that when such mismatch will no cause the fatal error and allow me to realize that the rate was changed and start the reconfiguration process again.

Any advice will be appreciated.

Thanks

Moshe

[MosheH]

Hi Edvin,

In addition to the above, the same framing UART error occurs also in the case that both parties are using the same baud rate (9600 in my case), but the nRF52 is being setup during a transmission of the external device, thus, once the external device is in the middle of transmitting its message over the UART interface while the nRF52 is initialized (using app_uart_init()), the nRF52 crashes.

Again, I will appreciate your help on solving this issue.

Thanks

Moshe

[Edvin]

Hello,

Sorry for the late reply. We are a bit short staffed during the summer vacation.

 

I understand. It sounds like you could use the APP_COMMUNICATION_ERROR event to detect when the other device has reset. 

I suggest that you do something like this (pseudo):

case APP_COMMUNICATION_ERROR:
    if (p_event->data.error_communication == framing error)
    {
        change_to_9600_baud();
        update_device_to_115200();
        change_to_115200_baud();
    }

 

As mentioned, the reason for the reset is because the error is passed on to APP_ERROR_HANDLER(). This will cause a reset. It is good for debugging and development, but it might not be a good thing in a product. It is better to use the APP_UART_COMMUNICATION_ERROR event to tell the application that something is wrong, and handle it properly. In your case, you can use it to detect the faulty baud rate, and an indication that the other device has reset, instead of resetting the nRF device as well.

 

Best regards,

Edvin