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