Hydra + MF4.1 + SPI + CS not working

Archive
1

Is there a known bug with SPI and Hydra running 4.1?

I’m running this code:


SpiPort = new GTI.SPI(socket, new GTI.SPI.Configuration(false, 1, 1, true, true, 1000), GTI.SPI.Sharing.Exclusive, Module);
byte[] Status1=new byte[5];
SpiPort.WriteRead(new byte[] {  CmdGetStatus,CmdNOP, CmdNOP, CmdNOP,CmdNOP},Status1);

But the problem is that CS never toggles.

I’m connected to Socket 3…

2

Just doublechecking you are connected th CS probe to pin 6, right?

3

I’ve run SPI on Hydra 4.1 without any issues. I’d agree, check your connection.

I also did my Hydra 4.1 SPI in regular NETMF instead of Gadgeteer…not sure if that will make a difference or not. Could be a mislabeled pin?

4

Yes, the LA was connected, traces from top to bottom, pin 9,8,7,6.

I will look into the Gadgeteer source to see if there is a bug in there…

5

I can test it if you want. I have same LA.

6

Thank you for the offer, but dont bother yet. I will step through the Gadgeteer stuff tomorrow morning. Its bed time now… :slight_smile:

If I cant see anything in the code then I’ll ask you to try…

7

Ok, sort of my fault.

If you don’t use the constructor where you specify the CS pin, then there is NO CS pin. The SPI port gets created with Socket.UnspecifiedPin as the CS pin… A bit backwards if you ask me. Why then lable a pin as CS when that pin isn’t, in any way, treated specially for the CS function.

I would think that if you don’t specify the pin then it should be the default CS pin. :slight_smile:

Edit:
I can now detect the number of devices in the chain by clocking through more bytes than there could ever be in the chain. In my case max four devices, so I clock through 5 bytes. Then I check where I get the first byte that I sent. In my case I get it back in the fourth byte, so there are three devices in the chain…

8

Great! That is good to know.