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

nRF52840 fails to go to low-power mode when using UART RX double buffering

Hello,

We are experiencing an issue when putting the nRF52840 back to a low-power state after having had UART configured for double buffering. For context we are using nRF5 SDK v15.3.0.

We have reverted to a very simple example application which does the following:

1. Initialize UART with the following configuration:

2. Setup a RX transfer for either a) single-buffering or b) double-buffering -> based on the following usage description "The secondary buffer can be set immediately after starting the transfer and will be filled when the primary buffer is full":

a)

b)

3. Transfer something over UART to trigger event handler

4. Un-initialize the UART on the event handler being triggered (we don't care about the data in this test case)

5. Finally, call nrf_pwr_mgmt_run() to wait until next event

We find that in the case of 2.a) the processor will return to a low-power state (~3.6uA) after the transfer, however in 2.b) it will not. We also experimented with use of nrfx_uarte_rx_abort but this seems to be unrelated.

We can likely work around the issue in the short term (simply by single buffering), however would like to understand where the issue lies so it can be improved in the future.

Any insight you can offer would be much appreciated,

Rob

  • Hi,

    Please try to update to latest nrfx driver, and see it that solves the issue. There was a bug-fixe when it comes to gracefully uinit of the UARTE peripheral in nrfx v1.7.2. See e.g. this post on this topic.

  • Hi Sigurd,

    Thanks for your help and suggestion.

    We have updated to the latest SDK v16.0.0, which has nrfx v1.8.0, however the problem is still present.

    I believe the UART changes in v1.7.2 were actually something we had experienced previously and had been working around by nrfx_uarte_tx_abort  after sending over UART. However, the changes do not seem to help us on the receive side, as described above.

    If you have any further pointers or could clarify the usage of double buffering on RX transfers that would be great.

    Best regards,

    Rob

  • Hi Sigurd,

    Further to the findings above, it seems that we are unable to abort from a RX transfer and successfully return to a low-power state (refer to the sequence below). It effectively means that only after the number of bytes configured by nrfx_uarte_rx() have been received can we successfully uninitialize the peripheral, which is simple but significant problem.

    Simple RX abort sequence (fails to return to low power mode, current is ~907uA)

    Note that we have tested this with SDK v16.0.0. Could you please let us know if there is something we're doing wrong here?

    Best regards,

    Rob

  • Hi,

    Simple RX abort sequence (fails to return to low power mode, current is ~907uA)

    I see the same behavior, and was able to reproduce it with this code:

    It might seem like the mention fix in nrfx only covers TX operation, and not RX. So the workaround mentioned by hmolesworth in the other post is still needed.

    If you are using UARTE0:

    For UARTE1:

    Edit:

    I did some testing, and it seems like waiting for the RXTO event after RX_STOPPED is triggered is required. I will report this to the nrfx team, and the fix will hopefully make it into the upcoming nrfx v2.1 relase.

    Edit2: Added a test for rx_buffer_length (Check if there is any ongoing reception)