Infinite loop in nrfx_uarte_uninit()

RE: Infinite loop in nrfx_uarte_uninit()

Susheel Nuguru — Tue, 25 May 2021 13:48:49 GMT

Sounds like a plan. Good luck :)

RE: Infinite loop in nrfx_uarte_uninit()

wcauchois — Tue, 25 May 2021 13:46:48 GMT

Ah, that's very insightful, thanks for the suggestion! I'll audit the uses of nrfx_uarte_tx() in our code and make sure we never send it in an interrupt (other than a UARTE interrupt, since that's disabled before the uninit() loop)

RE: Infinite loop in nrfx_uarte_uninit()

Susheel Nuguru — Tue, 25 May 2021 13:40:12 GMT

Yes, you are spot on to the text in the Low Power section which the developer also referred in his response. So the reason according to him to have wait states (forever loop was mistake, timeouts suits best) was that it is written in the PS to do so.

There could also be a race condition in your code, If you have this NRFX_WAIT_FOR interrupted with some interrupt context where you call nrfx_uarte_tx, then this function will clear the TXSTOPPED event before it triggers TASKS_STARTTX. And after this when the context comes back to the NRFX_WAIT_FOR then it will never have this event coming as it is already cleared by nrfx_uarte_tx. So I think we need to have a mutual exclusion between uninit and nrfx_uarte_tx so that there are no race conditions involved.

RE: Infinite loop in nrfx_uarte_uninit()

wcauchois — Tue, 25 May 2021 13:23:58 GMT

I think the nRF52840 Product Specification v1.2 (https://infocenter.nordicsemi.com/pdf/nRF52840_PS_v1.2.pdf) informs us here:

6.34.7 Low Power (page 514)

"The STOPTX and STOPRX tasks may not be always needed (the peripheral might already be stopped), but if STOPTX and/or STOPRX is sent, software shall wait until the TXSTOPPED and/or RXTO event is received in response, before disabling the peripheral through the ENABLE register."

The specification uses the word "shall". The document doesn't define what "shall" means, which is unfortunate, but it almost always means "if you don't do this, really bad things will happen and it's unclear if the part will work correctly afterwards".

So, you're suggesting that maybe we don't need to wait for RXTO/TXSTOPPED before disabling via ENABLE, but the part specification clearly says that we shall do that. Then at the same time, we see an infinite loop waiting for this condition, and discover that a not-yet-released newer version of the loop has a timeout.

I'm happy using the timeout because Nordic built it. I don't even need to understand why, though I'd like to.

If I had to boil this issue down to one question, it would be: "After timing out waiting for RXTO / TXSTOPPED in nrfx_uarte_uninit(), is it safe to later re-initialize and resume use of that same UARTE block?"

Do we need to wait for some amount of time before initializing it again, etc?

RE: Infinite loop in nrfx_uarte_uninit()

Susheel Nuguru — Tue, 25 May 2021 10:59:02 GMT

I have requested the developer to shed some light on this. But my feeling is that we do not need this check or wait state. But lets wait for the answer from the expert. I will comeback to you as soon as I hear something from him.

RE: Infinite loop in nrfx_uarte_uninit()

wcauchois — Mon, 24 May 2021 18:57:55 GMT

That said, in our specific case, p_cb->rx_buffer_length is always set to 1. We use the receive data event (ISR) to re-engage receiver with another 1-byte buffer, so there's no main-context scenario after we've enabled our receiver where rx_buffer_length is 0.

RE: Infinite loop in nrfx_uarte_uninit()

wcauchois — Mon, 24 May 2021 18:56:25 GMT

I think these questions could all be answered by the author of the latest change to the NRFX library I linked above, where the infinite loop was changed to have a timeout. Since that code looks like a fix for my exact issue, and it was written by a Nordic engineer, my preference is to hear the answer rather then help explore the problem :)

RE: Infinite loop in nrfx_uarte_uninit()

Susheel Nuguru — Mon, 24 May 2021 18:48:50 GMT

[quote user=""]1. Will the UARTE ever generate the NRF_UARTE_EVENT_RXTO event if the peer is not asserting RTS? That would cause an infinite loop in nrfx_uarte_uninit, since the peer is long-gone and is not asserting TX/RX/CTS/RTS at this point[/quote]

I am curious to know if you still have p_cb->rx_buffer_length non zero (ongoing transaction) while the peer sets signals of power off? In my opinion after triggering STOPTX and STOPRX tasks, the events should arrive nevertheless, but I might have to dig a more into the hardare internals if there are any conditions for this events not to arrive. Atleast there seems to be no blockers for these events from the product specification.

RE: Infinite loop in nrfx_uarte_uninit()

wcauchois — Mon, 24 May 2021 15:57:57 GMT

Update 2: I see that the latest version of NRFX also adds a timeout to nrfx_uarte_uninit():

https://github.com/NordicSemiconductor/nrfx/blob/master/drivers/src/nrfx_uarte.c#L332

void nrfx_uarte_uninit(nrfx_uarte_t const * p_instance)
{
    uarte_control_block_t * p_cb = &m_cb[p_instance->drv_inst_idx];
    NRF_UARTE_Type * p_reg = p_instance->p_reg;

    if (p_cb->handler)
    {
        interrupts_disable(p_instance);
    }
    // Make sure all transfers are finished before UARTE is disabled
    // to achieve the lowest power consumption.
    nrf_uarte_shorts_disable(p_reg, NRF_UARTE_SHORT_ENDRX_STARTRX);

    // Check if there is any ongoing reception.
    if (p_cb->rx_buffer_length)
    {
        nrf_uarte_event_clear(p_reg, NRF_UARTE_EVENT_RXTO);
        nrf_uarte_task_trigger(p_reg, NRF_UARTE_TASK_STOPRX);
    }

    nrf_uarte_event_clear(p_reg, NRF_UARTE_EVENT_TXSTOPPED);
    nrf_uarte_task_trigger(p_reg, NRF_UARTE_TASK_STOPTX);

    // Wait for TXSTOPPED event and for RXTO event, provided that there was ongoing reception.
    bool stopped;

    // The UARTE is able to receive up to four bytes after the STOPRX task has been triggered.
    // On lowest supported baud rate (1200 baud), with parity bit and two stop bits configured
    // (resulting in 12 bits per data byte sent), this may take up to 40 ms.
    NRFX_WAIT_FOR((nrf_uarte_event_check(p_reg, NRF_UARTE_EVENT_TXSTOPPED) &&
                  (!p_cb->rx_buffer_length || nrf_uarte_event_check(p_reg, NRF_UARTE_EVENT_RXTO))),
                  40000, 1, stopped);
    if (!stopped)
    {
        NRFX_LOG_ERROR("Failed to stop instance with base address: %p.", (void *)p_instance->p_reg);
    }

    nrf_uarte_disable(p_reg);
    pins_to_default(p_instance);

#if NRFX_CHECK(NRFX_PRS_ENABLED)
    nrfx_prs_release(p_reg);
#endif

    p_cb->state   = NRFX_DRV_STATE_UNINITIALIZED;
    p_cb->handler = NULL;
    NRFX_LOG_INFO("Instance uninitialized: %d.", p_instance->drv_inst_idx);
}

Please also provide the details of this discovery: what exact scenarios cause this loop to exit via the timeout?

RE: Infinite loop in nrfx_uarte_uninit()

wcauchois — Sun, 23 May 2021 20:18:07 GMT

Update: I added a hacked-up second version of nrfx_uarte_uninit() that looks like this:

void nrfx_uarte_uninit_2(nrfx_uarte_t const * p_instance)
{
    uarte_control_block_t * p_cb = &m_cb[p_instance->drv_inst_idx];
    NRF_UARTE_Type * p_reg = p_instance->p_reg;

    if (p_cb->handler)
    {
        interrupts_disable(p_instance);
    }
    // Make sure all transfers are finished before UARTE is disabled
    // to achieve the lowest power consumption.
    nrf_uarte_shorts_disable(p_reg, NRF_UARTE_SHORT_ENDRX_STARTRX);

    // Check if there is any ongoing reception.
    if (p_cb->rx_buffer_length)
    {
        nrf_uarte_event_clear(p_reg, NRF_UARTE_EVENT_RXTO);
        nrf_uarte_task_trigger(p_reg, NRF_UARTE_TASK_STOPRX);
    }

    nrf_uarte_event_clear(p_reg, NRF_UARTE_EVENT_TXSTOPPED);
    nrf_uarte_task_trigger(p_reg, NRF_UARTE_TASK_STOPTX);

    nrf_delay_ms(10); // CHANGE: enough time for RXTO, don't loop

    nrf_uarte_disable(p_reg);
    pins_to_default(p_instance);

#if NRFX_CHECK(NRFX_PRS_ENABLED)
    nrfx_prs_release(p_reg);
#endif

    p_cb->state   = NRFX_DRV_STATE_UNINITIALIZED;
    p_cb->handler = NULL;
    NRFX_LOG_INFO("Instance uninitialized: %d.", p_instance->drv_inst_idx);
}

Note the loop has been replaced with a 10-msec busy wait. This of course fixes the watchdog loop, but I really need guidance from a Nordic support engineer to learn if it's safe or not, in addition to answers from my original post.

I noted that in the SDK v15 version of this function, there is no loop. If anyone has an explanation for why that approach wasn't sufficient I'd also like to understand that.

Thanks,

Bill