Main Site Documentation

FEZ Raptor - UART Send Issue


#1

So I have a FEZ raptor board and I broke out the pins on one of the U Sockets so I have access to the RX/TX pins.

I also have a outside board (3DR Radio) I am trying to communicate with over UART Serial to from the FEZ Raptor. When I try to receive data, that works honky dory. However, when sending data it is like nothing happens at all. No exceptions happen on the SerialPort.Write however nothing is getting through to the outside module.

To test if the TX pin is even sending from the FEZ Raptor, I crossed it with the RX in pin that I confirmed is receiving on the FEZ Board. When I do this, absolutely nothing happens. I don’t get anything on receive, I just see the board is “sending” when I output to debug.

Is there anything I am doing wrong? I have tried different U-type sockets and still have the same issue.

Here is some sample code I created real fast to do the testing and this is what does not work.

        
       #region Test Functions
        private SerialPort testRadio = null;
        void ProgramStarted()
        {
            testRadio = new SerialPort(Socket.GetSocket(12, true, null, null).SerialPortName, 57600);
            testRadio.Open();
            testRadio.DataReceived += new SerialDataReceivedEventHandler(testRadio_DataReceived);

            //Main timer for radio transmission logic
            GT.Timer radioTransmissionLogic = new GT.Timer(500); //send at a slower rate than radio send
            radioTransmissionLogic.Tick += new GT.Timer.TickEventHandler(timer_Tick_UARTSEND);
            radioTransmissionLogic.Start();

            Debug.Print("Program Started");
        }

        void timer_Tick_UARTSEND(GT.Timer timer)
        {
            byte[] buffer = { 80 };
            testRadio.Write(buffer, 0, buffer.Length);
            Debug.Print("Byte Write: " + buffer[0]);
        }

        void testRadio_DataReceived(object sender, SerialDataReceivedEventArgs e)
        {
            Debug.Print("Byte read: " + testRadio.ReadByte());
        }

        #endregion

With the above code I do not even have the 3DR plugged in, simply cross the RX/TX pins on socket 12.

3DR Radio Wiki - http://copter.ardupilot.com/wiki/common-using-the-3dr-radio-for-telemetry-with-apm-and-px4/


#2

As a test to make sure the 3DR radio is working on the board side, I crossed it’s TX/RD pins and that works just fine. The same message get’s transmitted back to the other 3DR radio in that case.

The big thing is the TX out of the FEZ Raptor :frowning:


#3

Welcome to the forum !

If you don’t get anything received when you run that code, then there’s a hardware level issue.

I just ran the same code on a Cerberus with the socket connected to Socket 2, and I get a constant stream of:

[quote]Byte Write: 80
Byte read: 80
[/quote]

What pins do you have joined ? Should be pin4 and pin5.


#4

Yup, pins 4 & 5 are crossed.

Normally I would say the pins are maybe burnt out but I have tried 3 different sockets at this point. Any idea?

Just for reference I also have a “IO60P16” module plugged in on socket 15 and using the “UC Battery 4xAA Module” for debug.


#5

Also what I find interesting is if I let the TX/RX wires on the pins free (TX not pulled down to RX or anything else), the RX receives BYTE 80 from some interfere every couple seconds (along with a bunch of other noise).

So it must be sending somewhere? I don’t think I could test the TX line with a standard voltmeter could I?


#6

OK, so if you get the same situation on multiple sockets, then a soldering / connectivity issue just doesn’t make sense. Interference also doesn’t really make sense to me…

How have you connected your pins 4 & 5 together ?

I’ll ask another very important question - have you updated the firmware on your device ? Open Fez Config and check the loader and firmware match the SDK installed…


#7

I have a breakout board module (the cheapo ones that cost like $3 for 5) and I hooked from that into a breadboard and then on the breadboard crossed the wires.

Tried also switching out the breakout board for another, switching the ribbon cable for another and trying multiple plugs of the breadboard.

Everything on device is up-to-date to what is on the computer however I noticed I do not have the latest firmware that was released at the end of July, so let me go ahead and install all of that to the computer and the device. BRB :slight_smile:


#8

you don’t always need the latest firmware, but the absolute rule is that the firmware on your device must match the SDK version.


#9

Just out of curiosity, have you tried changing the socket number? I found that the COM port number on a native NETMF design for the G400 did not use the same serial port naming convention as the datasheet indicated that it was.


#10

Yup. Changed the socket. Don’t think that is the issue though as the RX pin works just fine for the socket I specify.

Now I am having a hard time putting the board into Loader mode :frowning:

Every time I cross pin 8 & 10 on socket 3 and restart, the computer still just recognizes the device as a “GHI NETMF Interface” and not a specific COM port.


#11

that means the connection to those pins is not being held reliably - not easy to do without a breakout unless you painstakingly go thru a controlled experiment (like I did)… here’s my experience that I can share !

Set up the raptor so that it’s stable and can’t move. Connect it up to the PC using USB. Have Device Manager open and have the PORTS section expanded so you’ll see if a new COM port pops up. Using only a paperclip in my right hand (naturally right handed), I touched pin 8 and pin 10 together into a Gadgeteer S socket, and with my left hand I pressed the reset button. If no new COM port appears, adjust paperclip and reset again. After 5 or so tries I was able to get this to go into Bootloader mode very reliably.

Edit: picture reference of the socket numbering is http://gadgeteer.codeplex.com/wikipage?title=Socket%20Type%20S