Serial Handshake

NETMF & Gadgeteer
1

In this latest release of NETMF/GHI SDK (GHI 4.1.3.0) were there any changes to the SerialPort? After upgrading I am getting overruns even at relativly slow speeds (115200) which should not happen with RTS/CTS enabled. Yes, the host app is using hardware settings and I tested input to the host CTS pin and it does in fact stop the flow of data. On my scope I can’t see that the Domino is toggling the RTS pin either, however I am admitedly not an expert scope user. I can clearly the see the TX pin activity on the scope, but nothing on the RTS. It stays low.

I am declaring the UART as follows:

                
UART = new SerialPort("COM2");
UART.BaudRate = 115200;
UART.DataBits = 8;
UART.Parity = Parity.None;
UART.StopBits = StopBits.One;
UART.Handshake = Handshake.RequestToSend;
UART.Open();

The following is the only code on the domino side to process data received:

            
        static void OnRecvUARTData(object sender, SerialDataReceivedEventArgs e)
        {   
            byte[] inBuffer = new byte[UART.BytesToRead];
            int count = 0;
            count = UART.Read(inBuffer, 0, inBuffer.Length);
            Debug.Print(count.ToString());
        {

Each time the the DataReceived event fires I get about 25-35 bytes @ 115200bps, but then it inevitabley gets exactly 192 bytes and then the overrun error occurs.

Prior to the upgrade I was able to run @ 460800bps without issue.

Any thoughts?

-AP

2

each time you are getting received event you are allocating a buffer.try to allocate the
Buffer once and reuse it.

You might be having a gc issue.

**this should not be an issue with hardware flow control.

3

Should not have posted it like that, sorry…the buffer is static. The behavior is what I described above.

        

static void OnRecvUARTData(object sender, SerialDataReceivedEventArgs e)
        {   
            int count = 0;
            count = UART.Read(inBuffer, 0, inBuffer.Length);
            Debug.Print(count.ToString());
        {

WinSSD indicates CTS status and despite sending gobs of data the CTS pin is never toggled, yet I get overrun errors. Further when I manually bring the CTS pin high on the Domino (using a 3.3v wire) data transfer stops.

So, because I suspect the pins are not working properly I went ahead and configured the UEXT5 pin as a general output port and tried to toggle it…guess what. Low is 25mv and high is 250mv…THE PIN IS DEAD! Right?

I am configuring the port with:


OutputPort rts = new OutputPort((Cpu.Pin)FEZ_Pin.Digital.UEXT5, false);

And then I am toggleing it with:

rts.Write(true);
rts.Write(false);
rts.Write(true);
etc
etc

Further, the CTS port (UEXT6) seems bad too. Similar voltages. I tried TX and RX and they work fine as output ports with the expected 0-3.3v levels.

I should see the full swing of 0-3.3v on all pins correct? This is a TTL pin right?

All this points to dead pins? How would I check that the SerialPort object is trying to toggle RTS? Is there a register somewhere I can check? The SerialPort class does not have a property to check pin status.

Thanks -AP

4

Just as a side note…I just tested ALL of Domino’s digital pins as ouputs and the ONLY 2 that are not working are the CTS/RTS on the UEXT header. Seems strange that IF I did something bad that I would have fried just those pins. Not saying its impossible that I did…I mean it wouldn’t be the first board I fried, but just can’t see how I did it and it seemed to coincide with the SDK update.

I think the next post should be on the “I fried my board” support forum.

-AP