Main Site Documentation

Fez Cobra II, pin out Error



I am getting a weird pin out error with the Cobra II and its extender board. The SPI socket on the Cobra II board is 6, I am using pin number 6 on socket 6 as a regular Digital Output Pin for an analog to digital(ADC) converter. I am also using the serial interface for another digital to analog converter(DAC) however the ChipSelect for this DAC is pin 6 on socket 7 on the extender board.

The problem is that when the SPI socket is instantiated pin 6 on socket 6 becomes high and outputs 3.3 volts even though the output is supposed to be set to 0V.

The following is the initialization code

//Digital output ADC initialization
private GTI.DigitalOutput _ADCpin;
private GT.Socket _ADCsocket = null;

_ADCsocket = GT.Socket.GetSocket(6, true, module, null);
_ADCpin = new GTI.DigitalOutput(_ADCsocket, pin.Six, false, module);

//Serial DAC initialization
private GTI.DigitalOutput _DACpin;
private GT.Socket _DACsocket = null;
_DACsocket = GT.Socket.GetSocket(7, true, module2, null);
_DACpin = new GTI.DigitalOutput(_DACsocket, pin.Six, false, module2);
GT.Socket _spiSocket; = GT.Socket.GetSocket(6, true, this, null)
 GTI.SPI.Configuration spiConfig = null;

spiConfig = new GTI.SPI.Configuration(false, ChipSelectSetupTime, ChipSelectHoldTime, false, true, ClockRateKHz);

GTI.SPI spiControl = new GTI.SPI(_spiSocket, spiConfig, GTI.SPI.Sharing.Shared, _DACsocket, _DACpin, this);


Right until the last line of code the output for pin 6 on Socket 6 is low however when the last line returns the output becomes high, would anyone know the reason for this?


In your code, when you create the GTI.SPI instance, you pass in _DACpin which is a DigitalOutput. The constructor actually expects GT.Socket.Pin.Six. That said, there is a bug in the Gadgeteer core itself from Microsoft. It mistakenly uses the SPI socket instead of the chip select socket for chip select. The only work around is to download the Gadgeteer source from and add Main/GadgeteerCore/Libraries/Core/SPI42/ to your project (you can use the following guide to aid you:

Then in SPI.cs, on line 223, change it to read “reservedSelectPin = chipSelectSocket.ReservePin(chipSelectPin, module);”


Thank you John, I had noticed these errors only happened after I updated to .netMF 4.2, in addition to this error I actually also received a CLR_E pin unavailable error as well if I was instantiate the SPI socket for a module and then try to use the another module with the default ChipSelect pin on the S socket. Do you know if this bug was existent in 4.1 as well?


I do not have the Gadgeteer source for 4.1 on hand, but I would imagine this bug was not present then. The bug looks like it was introduced when Gadgeteer was overhauled to support socket indirect in the latest release.


Hey John, after adding the SPI42 project to my solution the project itself requires a reference named Gadgeteer42.dll, do you know where I can find this reference.

In addition, to confirm, since I am adding this project into my solution I should remove the Gadgeteer.Spi.dll reference that I had added into my other projects previously and reference this project instead?


You can remove the Gadgeteer42.dll from the SPI42 project and add a reference to the Gadgeteer.dll found on your computer instead. And yes, if your other projects are affected by this bug, then you will want to reference this SPI42 project instead until the bug is fixed in a future Gadgeteer release.