Unexpected RXDRDY count

[Marco]

Hello,

I'm writing my own UARTE library because I need some functionality not offered in the SDK. But I came across a hardware behaviour I can't explain.

In my understanding, the RXDRDY event is triggered when a byte is fully received in the RX pin (at the stop bit). Then, after the RX FIFO and DMA it will eventually be written to RAM.

My code, similarly to libuarte_async, uses a TIMER to detect when there is no more activity in RX and another TIMER to count the number of RXDRDY events, which should represent the number of bytes physically received at the RX pin.

The problem is, the number of RXDRDY events is sometimes not what I would expect. For instance, consider this trace:

At [1], the RXTO irq handler runs because the DMA transfer is complete. As you can see, 78 bytes were received up to that point. The RXD.AMOUNT register reads 76 and the RXDRDY count is 77. I would expect the RXDRDY count to be 78.

Then, at [2], the RXTO irq handler runs because the reception is stopped due to RX idle. At this point, the RXD.AMOUNT register reads 14 and the RXDRDY count is 13. I would expect the RXDRDY count to be 12.

In short, it looks like the RXDRDY event is not triggered when a byte is received at the RX pin.

Can you please shed some light on this behaviour?

[Jørgen Holmefjord]

Hi,

Can you post your code showing how you configure the timer to count the events, and how you do the timeout?

Hard to see from your image, but is any of the bytes sent right after the RTS line is deactivated? The UART(E) peripheral has a HW RX FIFO that can hold up to 4 bytes, as described in the peripheral documentation. Do you trigger the STOPRX and/or FLUSHRX task at any point?

Best regards,
Jørgen

[Marco]

Jørgen Holmefjord Here's a capture with the events, as requested. GPIOTE is set to toggle the pins when the event occours.

Zoomed:

In this example:

21 bytes are received in the first block, but AMOUNT is 19 and RXDRDY count is 20. You can see that there was no RXDRDY event for the last byte. Instead, the RXDRDY for that byte occurs immediately before reasserting RTS. Here's a zoomed view:

[hmolesworth]

Interesting issue; since the first ENDRX is generated after 19 bytes which implies AMOUNT is correct assuming the stop was triggered by hitting MAXCOUNT minus the 4 bytes due to use of flow control so is the MAXCNT = 23? That first ENDRX was not issued by hitting the timeout. My interpretation is that the unexpected ENDRX count is correct depending on latency of interrupt generation:

"If the ENDRX event has not already been generated when the UARTE receiver has
come to a stop, which implies that all pending content in the RX FIFO has been moved to the RX
buffer, the UARTE will generate the ENDRX event explicitly even though the RX buffer is not full. In
this scenario the ENDRX event will be generated before the RXTO event is generated."

[Marco]

In my understanding, the ENDRX is triggered on MAXCNT, not MAXCNT-4. The 4 extra bytes can be stored in the RX FIFO.

Anyway, my concern are the RXDRDY events. The specs say

For each byte received over the RXD line, an RXDRDY event will be generated.

and the timing diagrams suggest that the event is raised immediately after a byte is received. My testing shows that the last RXDRDY event can be delayed until the UARTE is restarted.

[Jørgen Holmefjord]

Thank you for providing the traces. I have forwarded your findings to our HW team, to see if they can answer when the RXDRDY event is generated.

[Jørgen Holmefjord]

According to our HW team, the RXDRDY event should be generated after the STOP bit(s) as long as there is no OVERRUN error.

Can you provide code and instructions to reproduce this behavior? We would need to see the exact conditions to be able to check it further.

[Marco]

Is it possible that on ENDRX an internal clock is stopped and that causes the RXDRDY event to not trigger until it's restarted?

I can send you the source code privately if you provide an email address.

[Jørgen Holmefjord]

It is possible that something like that is happening, but there is one RXDRDY event generated after ENDRX in your logic traces.

Please send the project as a zip file in a private message to me. Alternatively, I can convert this case to private.