Reliable UART operation without handshaking

[Chris]

I have a small nRF51822 module that I want to use for UART communication without handshaking, and I'm having problems with reliability. Basically the nRF51822 crashes and reboots if I send a burst of data into its UART.

I've reverted to the ble_peripheral/ble_app_uart example from SDK 9.0.0, and the ONLY change I've made is to change APP_UART_FLOW_CONTROL_ENABLED to APP_UART_FLOW_CONTROL_DISABLED in the uart_init() function. My nRF51822 is wired as per the P10028 board (i.e. the UART TXD and RXD signals are connected to pins P09 and P11).

My nRF51822 module runs and I can connect to it from my phone, and using a PC with terminal emulator I can send individual characters through it to my phone without any problems. However, when I try to transmit a burst of data (by sending a small file from the terminal emulator) the nRF51 crashes and reboots even though the size of the data is well below the default UART_RX_BUF_SIZE value of 256.

I've tried both S110 SD 8.0.0 and S130 1.0.0. The software seems to cope with 50-100 bytes of data but crashes with a 200 byte burst.

Can the nRF51 work reliably without UART handshaking? Is there something else I need to do in the software to ensure reliable operation?

Thanks.

UPDATE: I've just found that the same problem occurs with handshaking enabled, and also happens with my nRF51 DK board. Can someone at Nordic please try the following:

• Program a nRF51 DK board as a peripheral using S110 or S130 and the standard ble_app_uart example.
• Establish a connection to the nRF51 DK board from a Central BLE device.
• Using a PC and a terminal emulator (I'm using TeraTerm), transmit a 200-byte file to the nRF51 DK board's COM port.
• The nRF51 crashes and reboots immediately.

However, I found if I modify TeraTerm to add a 1ms delay between characters then all the data is handled without problem.
It appears that the nRF51 cannot cope with a rapid burst of incoming UART data, regardless of whether handshaking is enabled or not.

[Susheel Nuguru]

Both Softdevice and UART without handshaking have realtime requirements. And Softdevice will not compromise as it runs on highest priority. It could delay the UART interrupt inside the driver which could make uart data loss. The crashes and reboots must happen in your application. So the bottom line is this uart driver with flow control disabled + softdevice will not perform well.

[Chris]

Thanks Aryan. Running the code using the debugger I can see that ble_nus_string_send returns error 0x3004. However on the next step NVIC_SystemReset is getting called (why?), causing the reboot.

Can you shed any light on what that error code indicates, and in what way it should be handled to avoid the reset? Could it be that, when the UART FIFO contains a lot of data, the existing uart_event_handle code is calling ble_nus_string_send too rapidly?