On XLR2 is anyone seeing that RTS output deasserts when CTS deasserts

[Mahendra Tailor]

On the XLR2 chipset I am seeing that if the RTS output follows the state of the CTS input. When I load the same firmware in a XLR then RTS does not follow CTS

[MartinBL]

Hi,

What XLR version are you referring to in your last sentence? To optimize power we made some changes when we migrated from XLR1 to XLR2. The changes are briefly mentioned in this Product Change Notification, but is porly documented.

In XLR2, when you set NRF_UART0->TASKS_STARTRX = 1 the RTS should not go low before your peer indicates that it has something to send by pulling CTS on the nRF51822 low. Not before CTS is pulled low will the nRF51 pull down its RTS indicating that it is ready to receive. I guess this implies that the RTS follows the CTS.

There are some UART related product anomalies in XLR2 that are fixed in XLR3, but I don't think they are relevant to your question.

[Mahendra Tailor]

The XLR chip returns 0x001D for the device ID The XLR2 chip returns 0x002A The XLR3 chip returns 0x006C

And please note you mention NRF_UART0->TASKS_STARTRX which may be not relevant.

The circumstance is that I have no uart traffic. I am not sending data and neither am I getting any data. All I do is drive the CTS input line and I see RTS follow that state. It is very easy to show without an oscilloscope because I have sent in via the support portal a terminal emulator called uwTerminal which displays the state of the modem status lines and also allows the states of RTS/DTR to be manipulated. So just changing RTS state results in a state change in the state of the PC's CTS line because the nrf's RTS output is connected to the CTS of the PC (and vice versa)

I had a look at the product anomalies and I don't see a mention of this behaviour

[RK]

This reminds me of this question devzone.nordicsemi.com/.../ from earlier this year which I didn't understand the answer to and didn't make sense to me.

That question was the other way around and was about the nrf raising the RTS line when the other side raised its RTS (connected to the nrf's CTS), but it seems like the same effect, one line follows the other.

As I said I didn't understand that answer at the time, the two signals should be entirely independent. it's quite possible to have one side ready to receive (thus holding its RTS line low) while the other side is not ready to receive (holding its RTS line high) and data could continue to flow in one direction forever. Just because the thing I'm connected to says it doesn't want to receive any more data, I don't see why that would mean I raise my RTS line and stop it sending.

Does this look like the same issue or am I just even more confused than I was in January?

[Mahendra Tailor]

Hi RK From your description, it is the same issue given RTS is connected to other's CTS and vice versa. Basically you are saying "about the nrf raising the RTS line when the other side raised its RTS (connected to the nrf's CTS)"

[MartinBL]

Hi. For future readers who might be interested in this case the conclusive, although vague, answer to this is: yes, the hardware guys confirm that in XLR2 the RTS output does follow the state of CTS. This behaviour is different from both XLR and XLR3, but is to be expected. The behaviour is not documented anywhere and sadly no one seems to remember the reason for the inconsistencies.