N+ RTS always high?

I'm having trouble implementing hardware flow control between an N+ and a Roving Networks RN-42 (as BlueSMiRF Silver). I've connected TX->RX, RX->TX, RTS->CTS, and CTS->RTS. I crossed RTS and CTS because the Roving Networks manual says that they should be crossed. My understanding is that in these crossed connections, RTS always sends and CTS always receives. So, I believe I want to see N+ RTS (D7) low until the N+ receive buffer starts to fill up, and N+ CTS (D8) low until the RN-42 receive buffer starts to fill up. What I actually see is the N+ RTS (D7) high all the time. When I watch with my 'scope, I can see that the RN-42 never sends data to N+ RX (D2) while N+ RTS is high. The only way I can get the RN-42 to send data to the N+ is by jumping D7 and D8, which brings both low. When D7 is low from jumping, I see the RN-42 sending data to N+ RX. I've set SerialPort.Handshake = Handshake.RequestToSend, which is what I believe enables hardware flow control on D7/D8. But, with no data flowing in either direction, I'd expect to see both D7 and D8 low -- but only D8 is low. A few random points: The high voltage on N+ RTS (D7) is 3.3V, so I know that's coming from the N+ (the RN-42 produces 5V signals). There are no problems with data flow from N+ to RN-42. I'm using COM2... D2,D3,D7,D8. I realize that I could just go without hardware flow control and almost never run into any problems. I just can't stand the idea of taking that chance (no matter how small) when I ought to be able to avoid it using hardware flow control. Any ideas about what might be going on, or how to further diagnose? Thanks

Hi Spork, Before going too far down this path...have you tried reversing the two (matching RTS to RTS and CTS to CTS)? Also, TX should mate with RX and vice-versa... Chris

I tried RTS to RTS and CTS to CTS, yesterday, but didn't take good notes about what was happening. I'll try it again but, in the meantime, here are the values I'm getting with no RTS/CTS connections at all (TX->RX connections are in place):

          NC    CONN
  CTS     0     0     <-- Low CTS on RN-42
  VCC     4.97  4.94
  GND     0     0
  TX      4.92  4.89  <-- Signals from RN-42 are 5V
  RX      3.31  3.31  <-- Signals from N+ are 3.3V
  RTS     0.03  0.03  <-- Low RTS on RN-42

  D8/CTS  3.28  3.28  <-- N+ has CTS high
  D7/RTS  3.28  3.28  <-- N+ has RTS high

Above, the six RN-42 pins are listed first, then D8 and D7 on N+. NC="BT not connected" and CONN="BT connected". No data has been sent or received, so buffers should be empty.

It seems odd that the RN-42 and N+ would disagree as to the initial CTS/RTS states. I would have expected them to match, except for the specific voltage levels. The RN-42 CTS and RTS levels are what I'd expect, but N+ levels seem high for no reason.

I use the SerialHelper code that was posted on these forums, modified so that handshake can be specified:

public SerialPortHelper(
    string portName = SerialPorts.COM1, 
    int baudRate = 9600, Parity parity = Parity.None, int dataBits = 8, StopBits stopBits = StopBits.One, 
    Handshake shake = Handshake.None)
{
    serialPort = new SerialPort(portName, baudRate, parity, dataBits, stopBits);
    serialPort.Handshake = shake;
    serialPort.ReadTimeout = 10; // Set to 10ms. Default is -1?!
    serialPort.DataReceived += new SerialDataReceivedEventHandler(serialPort_DataReceived);
    serialPort.Open();
}

I use the constructor like this (note COM2 and RequestToSend):

new SerialPortHelper("COM2", 115200, Parity.None, 8, StopBits.One, Handshake.RequestToSend);

Any thoughts on the initial disconnected condition of the RTSs and CTSs?

Ok... Let's boil this down to its bare essentials. Here's the simplest program I can think of that uses RTS and CTS:

using System;
using System.Net;
using System.Net.Sockets;
using System.Threading;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using SecretLabs.NETMF.Hardware;
using SecretLabs.NETMF.Hardware.NetduinoPlus;
using System.IO.Ports;

namespace NetduinoPlusApplication1
{
    public class Program
    {
        public static void Main()
        {
            SerialPort s = new SerialPort("COM2");
            s.Handshake = Handshake.RequestToSend;
            Debug.Print("Check D7 and D8");
            while (true)
            {
                Thread.Sleep(1000);
            }
        }
    }
}

If I have nothing connected to N+ RX, TX, GND, CTS, and RTS (just to be sure, I have nothing connected at all), what voltage should I measure on RTS (N+ D7) and CTS (N+ D8) when this program runs? I measure 3.3V on both D7 and D8, but I don't understand how this could be correct if hardware flow control is turned on with s.Handshake = Handshake.RequestToSend.

Hope somebody has some thoughts on the matter...

have you tried reversing the two (matching RTS to RTS and CTS to CTS)?

Was just reading the SAM7X512 data sheet to see what it says about CTS and RTS. Section 30.6.3.12 "Hardware Handshaking" says that RTS and CTS should be crossed, which matches what the data sheet for the RN-42 says.

It also says that "the remote device does not start transmitting while its CTS pin (driven by RTS) is high", which is the behavior I'm seeing. The RN-42 will not start transmitting because its CTS pin (driven by the N+ RTS) is always high.

More from the datasheet: "As soon as the Receiver is enabled, the RTS falls, indicating to the remote device that it can start transmitting. Defining a new buffer to the PDC clears the status bit RXBUFF and, as a result, asserts the pin RTS low." Shouldn't creating a serial port and setting Handshake to RequestToSend "enable the receiver" causing RTS to fall?

Hi Spork,

Ok... Let's boil this down to its bare essentials. Here's the simplest program I can think of that uses RTS and CTS:

            SerialPort s = new SerialPort("COM2");
            s.Handshake = Handshake.RequestToSend;

You'll need to add the following code to see any effect:

            s.Open();

I don't think that the .NET MF will change any pin settings until the port is opened.

Chris

Thanks... I've added s.Open() but I still get 3.28V on both A7 and A8.

SerialPort s = new SerialPort("COM2");
s.Handshake = Handshake.RequestToSend;
s.Open();

I'd appreciate it if somebody would volunteer to run this on their N+ to see if they get the same result.

Thanks... I've added s.Open() but I still get 3.28V on both A7 and A8.

SerialPort s = new SerialPort("COM2");
s.Handshake = Handshake.RequestToSend;
s.Open();

I'd appreciate it if somebody would volunteer to run this on their N+ to see if they get the same result.

I guess you mean port D7 and D8 instead of A7 and A8.

I can confirm this behaviour, even in the latest 4.2 build I have; 3.3V on D7 and D8 with that code.

But if I don't use the Handshake, and declare both pins as outputports with a low value, it works perfectly:

OutputPort p7 = new OutputPort(Pins.GPIO_PIN_D7, false);
OutputPort p8 = new OutputPort(Pins.GPIO_PIN_D8, false);
SerialPort s = new SerialPort("COM2"); 
//s.Handshake = Handshake.RequestToSend;
s.Open();

Would you please open this as a work item on the .NET MF 4.2 firmware (at netduino.codeplex.com)? And we can see if we can address it for the .NET MF 4.2 firmware (and then contribute any bugfixes back to Microsoft)? Chris

Thanks for checking this, Stefan! Yes, I did mean D7 and D8.

When you wrote "if I don't use the Handshake, and declare both pins as output ports with a low value, it works perfectly" you only meant that you get low levels on D7 and D8 and not that hardware flow control would work, right?

I hope I entered this correctly. See http://netduino.code....com/workitem/5

I hope I entered this correctly. See http://netduino.code....com/workitem/5

Thanks! I've voted and added a comment.

One thing about your sample code, perhaps you'll already know it, but:

while (true)
{
	Thread.Sleep(1000);
}

// Same as:

Thread.Sleep(Timeout.Infinite);

Heh... Never knew about Timeout.Infinite. Thanks again.