I have problems by using the SPI interface with the FEZ Spider board.
I use SPI2 module and can transmit the command to the slave but there is not answer on MISO pin. When I disconnect the slave MISO pin, I can measure the response on this pin. Thus, It seems to be a problem on FEZ Spider board side (probably, the MISO pin is an output and not an input). The MISO pin (IO38 or PIN61 on EMX board) is always zero.
Any ideas? Unterneath is my simple code:
using System;
using Microsoft.SPOT;
using Microsoft.SPOT.Presentation;
using Microsoft.SPOT.Presentation.Controls;
using Microsoft.SPOT.Presentation.Media;
using Microsoft.SPOT.Hardware;
using GT = Gadgeteer;
using GTM = Gadgeteer.Modules;
using Gadgeteer.Modules.GHIElectronics;
using GHIElectronics.NETMF.Hardware;
namespace GadgeteerApp1
{
public partial class Program
{
static SPI bpOS = null;
void ProgramStarted()
{
InputPort IRQ;
// IRQ: IO46
//IRQ = new InputPort((Cpu.Pin)EMX.Pin.IO18, false, Port.ResistorMode.PullUp);
IRQ = new InputPort((Cpu.Pin)EMX.Pin.IO38, false, Port.ResistorMode.PullUp);
SPI.Configuration bpOSConfig = new SPI.Configuration((Cpu.Pin)EMX.Pin.IO10, false, 10, 10, false, true, 125, SPI.SPI_module.SPI2);
bpOS = new SPI(bpOSConfig);
bool exit = false;
do
{
byte[] tx_data = new byte[7];
byte[] rx_data = new byte[7];
while (IRQ.Read() == true) ;
tx_data[0] = 0x80;
tx_data[1] = 0x05;
tx_data[2] = 0x80;
tx_data[3] = 0x10;
tx_data[4] = 0x00;
tx_data[5] = 0x00;
tx_data[6] = 0x00;
bpOS.WriteRead(tx_data, rx_data);
while (IRQ.Read() == false) ;
byte[] tx_data2 = new byte[28];
byte[] rx_data2 = new byte[28];
for (int i = 0; i < 28; i++)
{
tx_data2[i] = 0xFF;
rx_data2[i] = 0x00;
}
bpOS.WriteRead(tx_data2, rx_data2);
} while (exit == false);
// Do one-time tasks here
Debug.Print("Program Started");
}
}
}
The Spider uses EMX, using GHI’s commercial netmf library, so I think that if this was a general problem we would have seen it called out here many times before. So I suspect it’s more possible that there’s something specific on your board, or you’re not actually measuring the things you think you are. Can you help explain a bit more about what SPI device you’re connecting or whether you’re using an oscilloscope or something to measure the line?
Bi Brett
Thanks for your answer.
I agree - it is definitly not a gerneal problem. First some description about the SPI Slave:
It is a bluepulse RFID-Reader/Writer module (see www.bluepulse.info). The module itself works fine. As I described in my first post, the bluepulse module gets the answer and send the response through MISO pin. But I’m only able to see the response on the MISO pin, if I cut the path from module to FEZ spider. If the MISO pins are connected, the pin is always low. It seems that the pin direction is somehow wrong configured (for me it looks like the pin is configured as an output instead of an input).
I analyze the SPI communication with an oscilloscope - thus, I’m quite sure, that the pin is really low…
Is there a possibility to configure this MISO pin as a GPIO input pin? By doing so, I can check, if my hardware (FEZ spider) works correct.
My code is only for test purposes. I know, that I have to move the code somewhere out of the programstarted() method. But this should work for tests. Am I right?
OK, modified my response… Interrupts do not fire if you don’t let ProgramStarted() complete. I had not seen that you simply reading a pin that you’ve called IRQ - I thought you were trying to prove that the SPI is working by using an interrupt, and that just won’t work. But you are correct in that you should be able to read a pin value in ProgramStarted.
The fact that you have looked at the SPI comms via an o-scope means you probably have some other possible fault. Can you try a sample program to use that pin (even outside a Gadgeteer code, just using a standard EMX application) and toggle the pin to prove it’s working, and validate with the scope. Then, write another program that reads it’s value and wire it up to a different output and toggle it, checking that it works. Perhaps something is shorting out to GND, and if so then setting an output high that is connected to the pin shouldn’t read as high.
Ok. I thought, that this basic SPI communication works without interrupts. BTW: My IRQ-pin is not configured as an interrupt yet. Anyway, I’ll try to move my SPI related code outside of programstarted().
Regarding your hint to test the pin: I’ve tried this yesterday but without success. The pin was still low - even if I tied the pin manually to 3.3V. I was not sure, If I can use this dedicated pin as a general purpose I/O, since the EMX user manual says that this pin is only SPI MISO (or is MISO the 2nd feature and every pin can be configured as GPIO?).
IO38 and IO36 are the GPIOs for MISO/MOSI. Try a separate app that talks to both of them and connect them to your IO18 and see if that works on one and not the other. Importantly, don’t use SPI when you do that as you’ll steal the pin.
