Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

[nRF52832] ble_app_uart crashes on continuous data

I want to use nRF52-DK for receiving data over UART and send it over BLE link so I loaded the ble_app_uart but hard fault occurs immediately in these circumstances -
1. If input baud rate is different than the baud rate set in the app
2. If UART is receiving while the device boots
3. If UART data in received continuously

The first problem can be fixed easily but I cannot understand why the CPU is crashing instead of may be interpreting the data as junk like Arduino. The second problem is the same kind of problem but I can live with that. I cannot understand why the third one is happening and without it I cannot make my project work. I am using another microcontroller to send data over UART which consists of strings separated by new line. The peculiar thing is that when I put 50ms or more delay between two strings then everything works fine and I can receive data via nRF connect but if I reduce or remove the delay, the app immediately crashes when I connect the UART line. These solutions I have tried till now -

1. Migrating from SDK 15.1 to 15.2
2. Reducing UART baud rate from 115200 to 9600
3. Pulling up Rx line like suggested in this - https://devzone.nordicsemi.com/f/nordic-q-a/29183/ble_app_uart-crashes-with-error-4-nrf_error_no_mem
4. Increasing FIFO Rx buffer from default 256 to 1024

5. Commenting out BLE initialization

None of these seems to work. I am using SES and here's the log -

I apologize for uploading photos but I don't know how to convey this information better. I can also upload the main file but since I've only changed the buffer size and baud rate in the example it may not be necessary. 

  • Hello,

    I suspect what you are seeing is the uart_event_handle receiving an APP_UART_COMMUNICATION_ERROR, which is not necessarily triggered from the SW.

    I don't know which of the three cases you list the screenshot is from, but if you try to set a breakpoint on the line saying:

    case APP_UART_COMMUNICATION_ERROR:

    in main.c, you will figure out whether this is being called or not.

    Alternatively, if you define "DEBUG" in your preprocessor defines it should print in the log where the error comes from (might be useful for debugging). Note that the log module will suggest a reason for the error, e.g. NRF_ERROR_NO_MEM, like in the post that you link to, but the APP_UART_COMMUNICATION_ERROR register have different meanings than the normal error codes, so just look at the value, and check the register linked below.

    This event is typically caused if there is something weird going on on the UART, e.g. a mismatch in the baudrates.

    By default this event calls APP_ERROR_HANDLER(p_event->data.error_communication); so that you can check the type of communication error. As described in app_uart.h on line 117, it says that the communcation_error value contains the value in ERRORSRC register for the UART peripheral, which you can see meaning here.

    Note that if you don't want the application to restart due to a UART communcation error, you can remove this line, or maybe only reset on certain communication error values. That depends on your application.

    I suspect that the communcation error is the cause of the first two cases you list. As mentioned, a mismatch is a common cause. It may also be that if the other device is transmitting when you initialize the UART on the nRF it may only get  half a byte, which may also cause this event. You can e.g. set a flag after the first successful UART_RX event, don't care about the uart communication errors until this flag is set.

    The last one however, I am not quite sure. I suggest that you define DEBUG in your preprocessor defines, to see where this error comes from. It might be that you get an error in ble_nus_data_send, because your buffer fills up, if the BLE link can't keep up with the data that you transfer. Check your log to see which APP_ERROR_CHECK() or APP_ERROR_HANDLER() that causes the "crash".

    Best regards,

    Edvin

  • Thank you Edvin! I didn't enable debug config because I was actually running the example for PCA10040e as I wanted to run the example on nRF52810's limited resources.

    Anyway, I tested following setups -
    1. Changed the UART source MCU from ESP32 to ESP8266 and Arduino Uno (with level shifter) - still getting the same error
    2. Changed the example to PCA10040 for nRF52832 with debug config, changed Rx buffer from default 256 to 1024, reduced baud rate to 9600 - still getting the error. Here are the scree shots -

    [^This is after setting the breakpoint as you said, ERRORSRC is showing overrun and framing error]

    [^This is in debug config showing no memory error at APP_UART_COMMUNICATION_ERROR case]

    [^This is with Release config but the trace shows that the error occurred at APP_UART_FIFO_ERROR case]  

    I also tried changing the priority in APP_UART_FIFO_INIT to APP_IRQ_PRIORITY_HIGHEST but still cannot get rid of the error. 

  • Hello,

    As I mentioned the communcation error is probably caused by one of the messages being corrupted when you initialize the UART.

    You can chose to not pass these values into APP_ERROR_HANDLER();

    Does the application work if you ignore this event?

    BR,

    Edvin

  • Thank you Edvin! I have commented out both the error cases (APP_UART_COMMUNICATION_ERROR and APP_UART_FIFO_ERROR) and it's working!

    Besides that I changed the UART interrupt priority back to LOW because at HIGHEST it was preempting softdevice and throwing error while notifying. I also changed the Rx buffer back to 256(default) from 1024 and it's working alright.

    At 115200 baud rate I am getting some corrupted strings. At 9600 some strings are skipped because of BLE bottleneck but the ones I am getting are okay.

    Other thing to note here is that if I let my UART source running (i.e. ESP8266) and reset the DK then I am getting junk data but after resetting DK if I reset the source then it works fine. I think nRF52832 doesn't handle synchronization well and that could be the reason for the errors I was getting.

  • I found the solution for this if anyone is facing the same problem of connecting Rx line and getting garbage data -

    Instead of calling error handler on APP_UART_COMMUNICATION_ERROR and APP_UART_FIFO_ERROR, reset the uart module using this -

    app_uart_close();
    uart_init();

    It's recommended to just set a flag inside the uart_event_handle and then reset the uart from the main loop.

Related