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:

[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.

[Marco]

Hello Jørgen Holmefjord , just checking if you received the project.

[Jørgen Holmefjord]

Hi, sorry for the slow response. Yes, I have received the project and I'm working on reproducing the issue.

[Jørgen Holmefjord]

Hi,

Again, my apologies for the slow feedback on this request. I was able to reproduce the issue and received some feedback from our HW team on when the event is generated.

The RXDRDY event is generated every time a byte is moved to the top of the FIFO. This means that for the first 16 bytes, the data will be moved to RAM and the a new byte will me placed at the top of the FIFO when it is received. When the 17th byte is received, this will also be stored at the top of the FIFO and a RXDRDY event will be generated. However, since the RAM buffer is full (MAXCNT reached), the byte will be left in the FIFO until the UARTE is flushed/restarted. If you receive more data after the 17th byte, these bytes will be placed lower in the FIFO, and the RXDRDY events will first be generated when the data at the top of the FIFO is moved to RAM and a new byte is moved to the top of the FIFO.

Best regards,
Jørgen