Unexpected RXDRDY count

RE: Unexpected RXDRDY count

Jørgen Holmefjord — Thu, 13 Oct 2022 09:00:22 GMT

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

RE: Unexpected RXDRDY count

Jørgen Holmefjord — Tue, 05 Jul 2022 14:30:09 GMT

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

RE: Unexpected RXDRDY count

Marco — Thu, 30 Jun 2022 13:28:27 GMT

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

RE: Unexpected RXDRDY count

Jørgen Holmefjord — Thu, 23 Jun 2022 16:55:33 GMT

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.

RE: Unexpected RXDRDY count

Marco — Thu, 23 Jun 2022 15:25:51 GMT

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.

RE: Unexpected RXDRDY count

Jørgen Holmefjord — Wed, 22 Jun 2022 15:10:26 GMT

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.

RE: Unexpected RXDRDY count

Jørgen Holmefjord — Tue, 21 Jun 2022 16:24:14 GMT

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.

RE: Unexpected RXDRDY count

Marco — Mon, 20 Jun 2022 07:58:43 GMT

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.

RE: Unexpected RXDRDY count

hmolesworth — Fri, 17 Jun 2022 16:32:18 GMT

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

RE: Unexpected RXDRDY count

Marco — Fri, 17 Jun 2022 15:44:28 GMT

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:

RE: Unexpected RXDRDY count

Jørgen Holmefjord — Fri, 17 Jun 2022 12:58:52 GMT

Would you be able to output the events (RXDRDY, RXTO, END, COMPARE event) on GPIOs, to read out with the logic analyzer how the events are generated compared to your incoming data and task triggering? You can PPI and GPIOTE to setup this.

Also, if you can provide a minimal example that can be used to reproduce the behavior you are seeing, that would help us give you a better answer.

RE: Unexpected RXDRDY count

Marco — Thu, 16 Jun 2022 07:20:36 GMT

Jørgen Holmefjord Any update on this?

RE: Unexpected RXDRDY count

Marco — Tue, 14 Jun 2022 15:50:30 GMT

Here's the relevant code:

    //Configure RX count timer
    nrfx_timer_config_t tmr_config_count = NRFX_TIMER_DEFAULT_CONFIG;
    tmr_config_count.mode = NRF_TIMER_MODE_COUNTER;
    tmr_config_count.p_context = (void *)p_serial;
    ret = nrfx_timer_init(p_serial->p_timer_rxcount, &tmr_config_count, timer_rxcount_evt_handler);
    if (ret != NRFX_SUCCESS)
        return NRF_ERROR_INTERNAL;
    nrfx_timer_enable(p_serial->p_timer_rxcount);

    //Configure RX timeout timer
    nrfx_timer_config_t tmr_config_timeout = NRFX_TIMER_DEFAULT_CONFIG;
    tmr_config_timeout.frequency = NRF_TIMER_FREQ_1MHz;
    tmr_config_timeout.p_context = (void *)p_serial;
    ret = nrfx_timer_init(p_serial->p_timer_rxtimeout, &tmr_config_timeout, timer_rxtimeout_evt_handler);
    if (ret != NRFX_SUCCESS)
        return NRF_ERROR_INTERNAL;
    nrfx_timer_compare(p_serial->p_timer_rxtimeout, NRF_TIMER_CC_CHANNEL0, p_config->timeout_us, false);

    // ...
    
    //  When a byte is received, increment RX count timer
    PPI_CH_SETUP(p_serial->p_ctrl_blk->ppi_channels[SERIALPORT_PPI_CH_0],
                 nrf_uarte_event_address_get(p_serial->uarte, NRF_UARTE_EVENT_RXDRDY),
                 nrfx_timer_task_address_get(p_serial->p_timer_rxcount, NRF_TIMER_TASK_COUNT),
                 NULL);
    //  When a byte is received, restart RX timeout timer
    PPI_CH_SETUP(p_serial->p_ctrl_blk->ppi_channels[SERIALPORT_PPI_CH_1],
                 nrf_uarte_event_address_get(p_serial->uarte, NRF_UARTE_EVENT_RXDRDY),
                 nrfx_timer_task_address_get(p_serial->p_timer_rxtimeout, NRF_TIMER_TASK_START),
                 nrfx_timer_task_address_get(p_serial->p_timer_rxtimeout, NRF_TIMER_TASK_CLEAR));
    //  On RX timeout timer compare, stop it and stop UART RX
    PPI_CH_SETUP(p_serial->p_ctrl_blk->ppi_channels[SERIALPORT_PPI_CH_2],
                 nrfx_timer_compare_event_address_get(p_serial->p_timer_rxtimeout, 0),
                 nrfx_timer_task_address_get(p_serial->p_timer_rxtimeout, NRF_TIMER_TASK_STOP),
                 nrf_uarte_task_address_get(p_serial->uarte, NRF_UARTE_TASK_STOPRX));

When the RX timeout timer compares, it triggers the STOPRX task on the UARTE.

My RXTO irq handler then reads the RXD.AMOUNT register and the value of the other timer which I use to count the RXDRDY events.

On that image, no more bytes are sent when the RTS is deasserted.

No, I don't trigger FLUSHRX. If there's extra data in the RX FIFO, I'm fine with it being read when I setup the next DMA transaction, but I need to know if there's data there so I can manually restart the RX timeout timer. I need to do that because I manually stop the RX timeout timer at the beginning of the RXTO handler. Which, in turn, I do because the RX timeout timer is stopped by PPI on the RX timeout timer Compare event, but up to 4 extra bytes could be received, and those RXDRDY events would make PPI restart the RX timer.

It's a bit mind-bending, I hope that makes sense.

But I just want to know when the RXDRDY event is triggered. It appears it's not when the stop bit is received at the RX pin, like the docs suggest.

RE: Unexpected RXDRDY count

Jørgen Holmefjord — Tue, 14 Jun 2022 15:05:08 GMT

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