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

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

Mahendra Tailor — Tue, 19 May 2015 11:46:28 GMT

Thank you for the confirmation. We will be advising our customers that they should try to refrain deaserting their RTS as much as possible and expect that if they deassert RTS to stop the peer sending them data, then the XLR2 is also going to do the same and thus prevent you from sending data as well and thus reach a no-traffic either way scenario.

Important to understand the behaviour is fixed for XLR3.

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

MartinBL — Tue, 19 May 2015 10:50:48 GMT

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.

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

Mahendra Tailor — Fri, 15 May 2015 14:37:40 GMT

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

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

RK — Fri, 15 May 2015 13:04:50 GMT

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?

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

Mahendra Tailor — Fri, 15 May 2015 12:04:20 GMT

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

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

MartinBL — Fri, 15 May 2015 09:33:23 GMT

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.