This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

UART Stopping

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.

Parents
  • 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.

Reply
  • 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.

Children
No Data
Related