Async reads from UART do not return partial data

RE: Async reads from UART do not return partial data

Bart Cerneels — Fri, 29 Mar 2019 10:18:04 GMT

We have a copy of the SDK in a git repo and when I replaced nrfx I turned that directory into a submodule.

So here is the exact commit we are using:

d4ebe15f58de1442e3eed93b40d13930e7785903 nRF5_SDK_15.2.0_9412b96/modules/nrfx (v1.3.1)

It's from the repo git@github.com:NordicSemiconductor/nrfx.git

I would also request from Nordic to public their SDK on github like their other tools. This make it easy for us to use git submodule to include an exact version of the SDK in our codebase.

RE: Async reads from UART do not return partial data

Avanti — Wed, 27 Mar 2019 05:37:17 GMT

Hi, Can you point me to the NRFX module on github which is working?

RE: Async reads from UART do not return partial data

eric-appion — Fri, 15 Mar 2019 17:17:39 GMT

OK, will try that. Thanks!

RE: Async reads from UART do not return partial data

Bart Cerneels — Wed, 13 Mar 2019 08:30:15 GMT

Yes, it's working.

We just ended up replacing the NRFX module with the latest release from github.

RE: Async reads from UART do not return partial data

eric-appion — Tue, 12 Mar 2019 19:22:21 GMT

I've just run into the same problem. I want to use double-buffering to avoid dropping received characters when receiving at a high bit rate (921600 bps) without hardware flow control, and I'm calling nrfx_uarte_rx_abort() periodically to get any characters at the trailing end of a receive that don't fill the buffer, and I don't get the documented NRFX_UARTE_EVT_RX_DONE event.

Has anyone come up with a patch to the nrfx_uarte driver to get this working?

RE: Async reads from UART do not return partial data

MartinBL — Tue, 20 Nov 2018 14:13:27 GMT

Hi,

Thanks for reporting. I have found what seems to be a dormant internal bug report related to the issue. I'll try to revive it.

RE: Async reads from UART do not return partial data

Bart Cerneels — Mon, 19 Nov 2018 12:53:15 GMT

I'm in a similar situation trying to use UARTE on nrf52840.
I updated NRFX to the latest v1.3.1 tag but still don't get an RX_DONE event after nrfx_uarte_rx_abort(). In fact, stepping through the driver it's not even getting NRF_UARTE_EVENT_ENDRX.

This could be another bug or the result of nrfx_uarte not having good documentation, including an example.

RE: Async reads from UART do not return partial data

MartinBL — Fri, 16 Nov 2018 09:00:51 GMT

Can you please try the nrfx_uarte drivers found here? They are part of nrfx and they made some changes related to double buffering and RXTO in v1.2.0.

RE: Async reads from UART do not return partial data

rojer — Mon, 29 Oct 2018 16:24:33 GMT

hi Martin

well, wrt the way hardware functions, i guess that's fair enough.

my intention is to get whatever data has been received and process it.

let's go back to the description of nrfx_uarte_rx_abort(():

317 /**
318 * @brief Function for aborting any ongoing reception.
319 * @note @ref NRFX_UARTE_EVT_RX_DONE event will be generated in non-blocking mode.
320 * It will contain number of bytes received until abort was called. The event
321 * handler will be called from UARTE interrupt context.
322 *
323 * @param[in] p_instance Pointer to the driver instance structure.
324 */

currently, this does not happen when double buffering is used - RX_DONE driver-level event does not get raised. so we still have a driver-level bug.

in the end, i don't care that much whether internally it is precipitated by RXTO or ENDRX, but i need RX_DONE with the data accumulated in UART buffer so far.

looking inside the driver, and given the hardware behavior, it seems that my first suggestion of removing the check will work just fine in both cases, double-buffered and not. but as i said, ultimately i only care about the outcome - receiving RX_DONE with partial data when receive is double-buffered.

RE: Async reads from UART do not return partial data

MartinBL — Mon, 29 Oct 2018 16:11:42 GMT

Hi,

I talked to one of the architects behind the UARTE module and he said this is intended behavior. The spec says that:

"The UARTE will make sure that an impending ENDRX event will be generated before the RXTO event is generated."

If you enable the ENDRX_STARTRX shortcut it will ensure that a new RX starts immediately after the ENDRX event, before the RXTO event is triggered. The shortcut is then effectively resetting all the internal logic and timers in the UART module which hence disregards pending RXTO events. After the RX is started again it is as if the STOPRX task was never triggered.

I'm not sure where this leaves us though. I'm not sure I completely understand your problem and how it all connects yet.

RE: Async reads from UART do not return partial data

rojer — Fri, 19 Oct 2018 14:29:16 GMT

thanks, Martin

for now i just don't use double buffering in my app code and seem to be getting away with it fine, but it would be desirable (the hardware doesn't have flow control pins, unfortunately).

irrespective of RXTO behavior, i don't see any particular reason not to return partial data to the user, so juts removing that condition would deal with the issue as far as i'm concerned.

i also happened to notice that the manual very clearly says that one needs to flush the fifo first before the transfer is really done, but i don't see driver doing that. i haven't seen any data loss though, so maybe it's fine.

anyway, awaiting you response on this issue. thanks for looking into it.

RE: Async reads from UART do not return partial data

MartinBL — Fri, 19 Oct 2018 14:19:11 GMT

Hi,

Sorry for the late response. I have done some further digging and consulted SDK driver team, and regarding your first point; it turns out that you are not the first to report this. I also found some internal bug reports, but the guy responsible for them doesn't work for Nordic anymore and it seems like the report was forgotten about. I'll have to look further into this next week.

Regarding your last point the SDK team says that RXTO is enabled in the init and disabled in the uninit functions. So that means that RXTO interrupt should be enabled until the developer explicitly calls the uninit function.

RE: Async reads from UART do not return partial data

awneil — Sat, 13 Oct 2018 10:52:09 GMT

How to properly post source code:

RE: Async reads from UART do not return partial data

rojer — Fri, 12 Oct 2018 18:16:28 GMT

Ok, i experimented some more and it seem that RXTO is not raised at all if RXD is double-buffered, i.e. if transfer is aborted while there is second buffer available and the ENDRX->STARTRX short is enabled (which driver does).

here's what i did. at the top of uarte_irq_handler, i added this:

if (nrf_uarte_event_check(p_uarte, NRF_UARTE_EVENT_RXTO)) {
bsp_board_led_on(1);
}
if (nrf_uarte_event_check(p_uarte, NRF_UARTE_EVENT_ENDRX)) {
bsp_board_led_on(3);
}

when i only configure single buffer and do a short transfer, i get both leds to light up. when i configure second buffer, only LED4 light ups and RXTO is never triggered.

the manual doesn't mention anything about RXTO and double buffering interaction, so i suppose it should be the same. this smells like a silicon bug, actually

also, here, at the end of nrfx_uarte_rx, when interrupts are enabled for the async case:

438 {
439 nrf_uarte_int_enable(p_instance->p_reg, NRF_UARTE_INT_ERROR_MASK |
440 NRF_UARTE_INT_ENDRX_MASK);
441 }

isn't NRF_UARTE_INT_RXTO_MASK supposed to be there as well?

RE: Async reads from UART do not return partial data

rojer — Fri, 12 Oct 2018 15:20:27 GMT

what you say makes sense, but i also wasn't just browsing around the driver code to find this.

i definitely was not getting partial RX_DONE events until i identified and disabled that check.

RE: Async reads from UART do not return partial data

MartinBL — Fri, 12 Oct 2018 15:15:47 GMT

Hi,

I'm not sure if I agree. If you look at Figure 4. UARTE reception with forced stop via STOPRX you can see that you should get an RXTO event after you trigger the STOPRX task (which is what happens when you call nrfx_uarte_rx_abort()). If you look in the nrfx_uarte drivers you can see that this event calls the RX DONE event:

// nrfx_uart.c line 549:
if (nrf_uarte_event_check(p_uarte, NRF_UARTE_EVENT_RXTO))
{
    nrf_uarte_event_clear(p_uarte, NRF_UARTE_EVENT_RXTO);
    if (p_cb->rx_buffer_length)
    {
        p_cb->rx_buffer_length = 0;
        rx_done_event(p_cb, nrf_uarte_rx_amount_get(p_uarte), p_cb->p_rx_buffer);
    }
}

As far as I understand, this event should provide you with the bytes received up until abort was called.