This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

UART RTS signal behavior when STARTRX

Hi Nordic guys,

we are using uart for communication with another MCU and flow control is used. Beside the uart communication itself we have out of band signals (on gpio) used to indicates to other MCU if each side would communicate over uart or not (it is a power handshaking logic). When nobody wants to talk both sides will disable uart (on Nordic side we just STOPRX/TX task.

Now when Nordic set to H the RTS due to 4 byte left in uart fifo, the other side will avoid sending out a byte (it is just polling the RTS and acts consequently), and retries a little later. During this time power handshaking let sleep uart on both side.

Note that in one specific case the app on nordic will deactivate interupt for received byte on uart since it won't be able to process it and would intentionally blocks the uart traffic letting RTS be triggered.

So on Nordic we are in this situation:

  1. app disable RXDRDY interrupt in INTENCLR;

  2. RXD fifo contains 2 bytes so RTS is set to H;

  3. other MCU set idle state for uart and so Nordic will STOPRX (here RTS will be deactivated.. but it is already to H on step 2)

  4. other MCU waits a while and 'wake' uart so Nordic STARTRX task

The question is: what is the expectation for the RTS signal? The Reference manual shows in the diagram that RTS goes L when STARTRX. Is it always true regardless the status of RXD fifo? Elsewhere in manual it is written that "RTS signal will first activated again when the FIFO has been emptied".

Is an OR logic implemented for above conditions (RTS goes L if "STARTRX" or "rx fifo empty") are an AND one?

Could you clarify it? As per our test is seems that RTS is activated every time at STARTRX regardless status of RX fifo.

Thanks

  • Hi Nordic guys,

    sharing an other finding we get in our code.

    Due to mentioned bvehavior in UART module we would expect on our side to have bytes lost on Nordic since the RTS is not more reliable and it seems uart fifo is flushed. Anyway we do not observe any bytes lost.

    The reason is that we do have RXTO as source of ISR and the ISR on RXTO event read the RXD till is set so basically flushing the uart fifo. So when STOPRX happens the RXTO will be triggered later (internal uart timeout to let 4 bytes being transmitted based on configured baud-rate as per Nordic manual) having the ISR flushing the uart fifo. This explain on our side why at the end when STARTRX is enabled later the content of UART fifo will correctly set the RTS to enabled. We will avoid STOPRX/STRTRX cycle to avoid this. Thanks

Related