Reliable UART operation without handshaking

RE: Reliable UART operation without handshaking

Chris — Wed, 04 Nov 2015 12:51:30 GMT

Many thanks for all the help, using your advice and looking at other answers I've restructured the code along the lines described at devzone.nordicsemi.com/.../ It now seems a lot more reliable.

RE: Reliable UART operation without handshaking

Susheel Nuguru — Wed, 04 Nov 2015 12:04:11 GMT

That invalid state error is useful if we are trying to send any data before connection is established.

RE: Reliable UART operation without handshaking

Susheel Nuguru — Wed, 04 Nov 2015 12:02:25 GMT

As I mentioned in my comment, 0x3004 is BLE_ERROR_NO_TX_BUFFERS . So the softdevice ran out of TX buffers to transmit your data, which means that UART is sending faster than softdevice could handle.

When you get this error, your application should stop sending data and wait for BLE_EVT_TX_COMPLETE event. After getting this event it means that there is more room for TX and then more uart data can be transmitted over BLE. Search the forum for this event and you will find tons of information.

Regarding the system reset APP_ERROR_CHECK macro will do a system reset whenever the error code is not equal to NRF_SUCCESS. You can change this behavior by changing app_error_handler (inside app_error.c) code.

RE: Reliable UART operation without handshaking

Chris — Wed, 04 Nov 2015 10:57:42 GMT

Also the existing call to ble_nus_string_send is followed by a check that throws an error if err_code != NRF_ERROR_INVALID_STATE, rather than NRF_SUCCESS. The SDK documentation doesn't explain this (it says ble_nus_string_send should return NRF_SUCCESS). Can you clarify this?

RE: Reliable UART operation without handshaking

Chris — Wed, 04 Nov 2015 10:39:19 GMT

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?

RE: Reliable UART operation without handshaking

Susheel Nuguru — Wed, 04 Nov 2015 09:59:55 GMT

you are right, This example is not written for bulk data transfer. There is an error happening in main.c->uart_event_handle()->APP_UART_DATA_READY->ble_nus_string_send->returns 0x3004 (BLE_ERROR_NO_TX_BUFFERS)

If you handle it then i guess you are good to go.

RE: Reliable UART operation without handshaking

Susheel Nuguru — Wed, 04 Nov 2015 09:35:17 GMT

sorry, i missed to see that you said that the flow control is enabled in your update. I will try it out and see

RE: Reliable UART operation without handshaking

Chris — Wed, 04 Nov 2015 09:07:29 GMT

Hi, the issue I described in the update to my question was using Nordic's ble_app_uart example without any modifications, with flow control enabled, so the code was entirely Nordic's. Hence I don't believe the crashes and reboots can be attributed to my application.

Could someone at Nordic try to replicate my observations?

RE: Reliable UART operation without handshaking

Susheel Nuguru — Wed, 04 Nov 2015 08:49:21 GMT

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.

RE: Reliable UART operation without handshaking

Nguyen Hoan Hoang — Tue, 03 Nov 2015 16:51:36 GMT

I found that when you do a continuous send with sd_ble_gatts_hvx, the first 6 time no error. After that it starts returning error. After the third consecutive error, that fourth one resets the board.

RE: Reliable UART operation without handshaking

Chris — Tue, 03 Nov 2015 15:28:50 GMT

I've already tried running in debug mode and as far as I could tell there was no assert nor any error codes. I'll keep digging into it.

Regardless, the standard SDK code really ought not to crash - if the UART buffer gets full (and mine was nowhere near full) then I would prefer it to simply ignore any further input or flush the buffer, not reboot! It would be useful to know how the SDK is supposed to behave in this scenario.

RE: Reliable UART operation without handshaking

Alex — Tue, 03 Nov 2015 14:44:48 GMT

You need handshaking anyway because MCU/PC which sends data via UART to nRF51 doesn't know if data passed over to your phone or still in the buffer. If you have hardware limitations and can't use hardware handshaking you can modify your code to use software habdshaking but throughout will be even lower. But if you know that the buffer is not filled yet then try to run in debug mode and check which code line makes nRF51 crash.

RE: Reliable UART operation without handshaking

Chris — Tue, 03 Nov 2015 14:15:12 GMT

I've found it seems to work more reliably if the baud rate is reduced from the default 38400 to 9600.