Cobra II Eco Serial Port Problem

Archive
1

I’m getting the error:

“Socket 11 has an error with its Serial functionality. Please try a different socket.”

The definition of the socket passes, but when “new GTI.Serial” is called the error appears. Below is the definition of the socket and the call I’m making that generates the exception. I’m using the Cobra II with the extension board. I’ve tried socket 8 and I get the same error. So I thought I would define the socket myself and see what happens.

GT.Socket socket = GT.Socket.SocketInterfaces.CreateNumberedSocket( 11 );
socket.SupportedTypes = new[] { ‘I’,‘K’,‘U’,‘X’ };
socket.CpuPins[3] = Pin.P0_4;
socket.CpuPins[4] = Pin.P4_28;
socket.CpuPins[5] = Pin.P4_29;
socket.CpuPins[6] = Pin.P1_30;
socket.CpuPins[7] = Pin.P3_26;
socket.CpuPins[8] = Pin.P3_25;
socket.CpuPins[9] = Pin.P3_24;
try
{
GT.Socket.SocketInterfaces.RegisterSocket( socket );
Debug.Print( “Success Creating Socket #11…” );
}
catch ( Exception ex )
{
Debug.Print( "Exception Registering Socket #11: " + ex.Message );
return;
}

socket = Socket.GetSocket(socketNumber, true, this, null);
pwrkey = new GTI.DigitalOutput(socket, Socket.Pin.Three, false, this);
serialLine = new GTI.Serial(socket, 19200, GTI.Serial.SerialParity.None, GTI.Serial.SerialStopBits.One, 8, GTI.Serial.HardwareFlowControl.Required, this);

What am I doing wrong?

2

You definition of the socket must be conflicting with the one that is created by mainboard class. Can you show your original code, please?

3

In the original code I was calling

socket = Socket.GetSocket(socketNumber, true, this, null);

passing the socketNumber=8

The problem is I’m not getting any responses from the device that I’m communication with which happens to be the Cellular module via the CellularRadio software that is on the Forum. I get no errors, but I don’t get any “OK” from the modem. This works on a Spider without issue.

4

Are you getting the errors with the socket definitions that we provide in the Cobra II mainboard? Or were they only with your definitions?

5

No errors with socket definitions… Just not receiving data back from the Cellular Modem. Not sure if the IRQ is not being fired or if the control lines are handshaking properly. I could put a protocol analyzer on the lines to see what they are doing if that helps.

6

You have mentioned “CellularRadio software that is on the Forum”. Do you have a link?

7

I stand corrected… The driver I’m using is from seeed. I found it on their site. In any case the module works with the same driver on a Spider unit and all I was doing was including it in my Cobra II solution. I couldn’t get socket 8 to work as it would not receive any data from the module. So I was trying to define a new socket and make sure that all the signal lines were setup properly. This is when I ran into the problem with the redefinition of the socket that started me logging the problem here on the Forum.

Here is a link to the driver I downloaded:

http://www.seeedstudio.com/depot/cellular-radio-net-gadgeteer-compatible-p-976.html?cPath=73

8

Could you hook it up to the analyzer and see what is going on with the lines when compared to the Spider?

9

Yes I can hook up the analyzer and compare the two devices.

10

I found the problem! The Cobra Extender calls out IKUX on port 8. K is a serial port and I hooked the modem to this port. It doesn’t work… No data comes from this port. But if I hookup to port 7, which ISN’T labeled K just PUY it works. I have not dug deeper into the I/O lines, but something tells me that port 8 really isn’t a serial port, or not one that allows hardware handshaking. In any case the Cellular Modem does work off of port 7.

11

You are not the first who observed this Issue

https://www.ghielectronics.com/community/forum/topic?id=12586

12

@ RoSchmi - Thanks for the info… Sometimes the search results on the forum are so numerous that it is hard to find other issues that really correspond to what you are searching for. Next time I’ll try to be a little more definitive on my search criteria.

13

It is good to know that it is not just me!
The ‘U’ ports should support serial. Cobra II ports 5 and 7 work.
Port 8 is “IKUX”, but does not work for RS232. From the looks of it, Port 8 should support hardware flow control (COM2) - the other don’t. (so that may be somewhere to look)

14

I recently hooked up a Seeed Studio cellular modem to a Cobra 2.

If you use the Gadgeteer it won’t connect to socket 5 on the Cobra 2 even though this is a U socket. It seems it is looking for RTS and CTS.

I don’t have the extender board and I was not going to be using socket based IO and would use the SerialPort class direct.

Socket 5 has no connections for the handshake line and CTS is connected to a pin that has no connection.

RTS is however connected to a GPIO pin and I had issues with the modem not responding at first. I wasn’t worrying about handshaking for the application as all I need is SMS only.

I then enabled the GPIO and set this LOW and the modem started working.

15

It appears that the Cobra II driver has Socket 8 marked as COM3 mistakenly.

@ csailor, could you download the Cobra II driver from http://gadgeteer.codeplex.com/SourceControl/latest and add the project found under Main/Mainboards/GHIElectronics/FEZCobra II/Software/FEZCobra II/FEZCobra_II_42/ to your solution? Then add that project as a reference to your main project and remove the old GHIElectronics.Gadgeteer.FEZCobra_II.dll reference? In the FEZCobra_II_42.cs file, change line 254 “socket.SerialPortName = “COM3”;” to read “socket.SerialPortName = “COM2”;” instead and see if that allows socket 8 to work?

1 Like
16

@ John -
Does Socket 8 or any other socket support hardware flowcontrol?

17

COM2 does have hardware flow control (CTS and RTS) mapped to the proper pins on Socket 8. Flow control should work once the driver is modified to use COM2.

18

Thank you for looking into this. I can confirm that setting:
socket.SerialPortName = “COM2”;
fixes the serial port issue with Socket 8. I tried two devices and they both work fine when I initialize with Serial.HardwareFlowControl.NotRequired.

I can’t confirm that the hardware flow control works. My initial tests fail with HardwareFlowControl ‘UseIfAvailble’ or ‘Required’. I have not had a chance to debug yet. (check the cables & check if the devices support HW control – one says “no hw/sw handshaking required”; the other says RTS=busy, DTR/DCD/DSR=short, CTS=nc)
I personally don’t need HW control, so I may not get around to finishing the testing soon.

19

Do you by any chance have a SPI device on socket 9? One of the SPI pins on socket 9 is the same pin as a flow control pin on socket 8, so if you use the pin as SPI, you can’t use it as flow control and vice versa. The mainboard definition has been updated to reflect that when using a module that mandates flowcontrol in the coming release.

20

That would do it. ENC28 on socket 6, so I put my N18 display on socket 9 (real-time debugger :)) I disconnected socket 9 and now socket 8/COM2 flow control works. Thank you. I can’t give up socket 9 so I won’t use HW flow control, but I can sleep better at night understanding what is going on!