UART Stopping

[Mark J]

We have noticed an issue when using the UART on our nRF51822 (SoftDevice = S130, nRF51_SDK_9.0.0_2e23562). Our Nordic app waits for commands on the UART and processes these commands when they come in. A Linux host app sends these commands periodically over RS-232 to do things like tell the Nordic app to scan for advertisers and reply with scanned devices. Commands were being processed fine for about 10 min before the UART stopped passing incoming commands to our Nordic app. After more closely referencing example apps, we added sd_app_evt_wait() calls between UART byte reads (app_uart_get() calls) and this seemed to fix the issue. We are unsure how this fixed the issue as examples did not clarify (specifically) the point of the sd_app_evt_wait() calls.

Is this expected behaviour? Our concern is that we may be working around an issue that might surface again when our devices are run in the field (e.g. maybe the UART will now stop passing incoming bytes after days and not minutes). If adding sd_app_evt_wait() makes sense as a fix, we will move on. Clarification as to how this call addresses the issue is appreciated.

Thanks in advance.

[RK]

I think you ought to be able to just hammer the thing into the ground constantly without any kind of wait and it shouldn't hang on you. So if it does hang, it sounds like a bug to me and it shouldn't do it.

'wait after fail' is how the API was designed to be used and is much lower power and generally less brutal way to do it so you should do that anyway as you are doing.

So my slightly unhelpful take on it is that if it hangs when you just call it repeatedly without waits thats buggy, however if it works when used in a more anticipated way using waits when the uart reports it's not yet ready before trying again, that's how it was designed to work and you should be pretty confident using it that way; as well as it just being a good power-saving practice.