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]

What is app_uart_get() doing before you add the app event waits? Is it returning an error code or not returning at all or what? The documentation for that function tells you that if there's no character to read then it returns an error code and will generate an event when a byte comes in. The event coming in would trigger sd_app_evt_wait() to return so I can see how putting them in might be working, however what you should be doing is reading the character, if one is returned, processing it, if it's an error returned, then use sd_app_event_wait()

while( app_uart_get( .. ) != NRF_SUCCESS )
    sd_app_evt_wait()
// process your character here

more like that

[Mark J]

Thank you RK for replying.

app_uart_get() is just reading byte for byte as all examples show. In this specific case, it appeared to be returning with a result other than NRF_SUCCESS and staying in the while loop (before we added sd_app_evt_wait() as shown in examples and in your reply above). This has to be the case as sd_app_evt_wait() calls have fixed our issue. What we are really trying to understand is why the addition of sd_app_evt_wait() makes a difference. This is important to us so that we can understand if our issue has been resolved. To clarify, after adding the sd_app_evt_wait() call - the UART no longer seems to stop. We would just like to understand why or how the addition of this call makes a difference to feel comfortable that the issue is completely resolved.

[RK]

"staying in the while loop"

What while loop? There's a whole range of ways you could have written it. Are you saying you're just banging repeatedly on the uart trying to get a character, if the call returns something other than success you bang on it again and try to get it again in tight loop?

[Mark J]

The while loop enclosing the app_uart_get() call ... just as you have shown it and just as it is shown in countless examples. "if the call returns something other than success you bang on it again and try to get it again in tight loop?" ... isn't that what "while( app_uart_get( .. ) != NRF_SUCCESS )" does?

[RK]

well actually no - that's not what the code I posted does - mine does not bang on the uart, If the call returns NRF_SUCCESS then it processes, else it does an app event wait and only then tries again. So it loops, throttled by events, until it gets a character.

That's different from the other two possibilities your original message allows (since you didn't post any code) which are

1. just call app_uart_get() in a loop constantly until it returns NRF_SUCCESS. That's what I describe as 'banging' the uart.
2. call app_uart_get() and then always follow it with sd_app_evt_wait() whatever it returns, which is what your original message hints you're actually doing.

1 is pretty brual, should work, but not great practice. 2. has more waits than needed but will return shortly after a new input. What I posted attempts to follow the documentation of the function and wait only when necessary.