# Arduino SPI not transmitting

I am trying to drive a MAX7219 LED controller and 8x8 LED Matrix via SPI from my Arduino MEGA 2560. I can control the MAX7219 via SPI using my Bus Pirate, but for whatever reason, when I try to control it from Arduino (code below) I get no response. Furthermore, I connected my Bus Pirate to my Arduino SPI pins and put it in sniffing mode, and it shows no communication, whether or not CS is low. Does anyone have any idea why this is not working?

Code:

#include "SPI.h"

void setup() {
pinMode(10, OUTPUT);
lcd.begin(20,4);
SPI.begin();
pinMode(13, INPUT);
}

void spiWrite(byte reg, byte data){
digitalWrite(10, LOW);
SPI.transfer(reg);
SPI.transfer(data);
digitalWrite(10, HIGH);
}

void resetMAX(){
spiWrite(0x0f, 1);
spiWrite(0x0c, 1);
spiWrite(0x02, 13);
}

void loop() {

resetMAX();
} else {
spiWrite(0x0f, 0);
}
}


I am using the SPI pins on the ICSP header (Clock = 3, MOSI = 4) and Pin 10 (on the PWM side of the arduino) for the Slave Select. On Pin 13, I have a switch to enable sending different commands to the MAX7219, though that is currently having no effect, since it seems I am sending no SPI commands at all. Thoughts?

• Are you scoping 50,51,52 and 53? – mpflaga Jan 22 '14 at 2:51
• I wonder... are you selecting 'Arduino Mega 2560' in the Arduino IDE boards menu? Do you have the latest version of the IDE? – geometrikal Jan 22 '14 at 3:26
• @mpflaga, I think you are referring to an oscilloscope, and no, I do not own one. – therealmitchconnors Jan 22 '14 at 5:31
• @geometrikal, I have the latest IDE for windows, and the correct COM port and board selected. I have uploaded many sketches (not using SPI) successfully using this setup. – therealmitchconnors Jan 22 '14 at 5:33
• I suggest start from something that works. perhaps try running DigitalPotControl.ino and scoping it with your bus pirate. and if that fails to show anything. Then fall back to an UNO, where you can be assured it should work. And then get the scope working and them migrate forward, step by step. (I often have to do this, to find the obstacle that was or was not obvious.) – mpflaga Jan 25 '14 at 3:37

I found this on the Arduino SPI page http://arduino.cc/en/Reference/SPI

Note about Slave Select (SS) pin on AVR based boards

All AVR based boards have an SS pin that is useful when they act as a slave controlled by an external master. Since this library supports only master mode, this pin should be set always as OUTPUT otherwise the SPI interface could be put automatically into slave mode by hardware, rendering the library inoperative. It is, however, possible to use any pin as the Slave Select (SS) for the devices. For example, the Arduino Ethernet shield uses pin 4 to control the SPI connection to the on-board SD card, and pin 10 to control the connection to the Ethernet controller.

Not sure if it will fix the problem, so far most of my boards have used the SS pin as an output regardless.

• Ss (d10) is often the culprit. However d10 in this case is the required output for master mode. Correct thinking in that it is a conflict, as it is d13. – mpflaga Jan 21 '14 at 3:26
• FYI, the spi.begin() will set the SS as an output. So as long as it is not messed with at a later time. Where as all pins are default HiZ input. So SS should be good to go here. Something else. – mpflaga Jan 22 '14 at 2:59
• I am not certain I am following this thread... in my code, D10 is the SS pin, and is set up as an output. On the 2560, D13 does not appear to have any relation to SPI operations... see the diagram for details – therealmitchconnors Jan 22 '14 at 5:37
• There is a dedicated hardware SS pin. If set to input, the 2560 will be put into SPI slave mode and you won't be able to send SPI messages. We were thinking 13 was this pin. The dedicated SS pin doesn't have to be used for master mode though. – geometrikal Jan 22 '14 at 11:53

D13 is the spi clock. It needs to be an output. not an input as you have it. With this as an input your spi is a slave and needs clock driven into it. Hence you see nothing. You want your spi to be master and drive the clock to the peripherals.

Move your switch input for led reset to an unused pin.

• On the mega 2560 are the SPI pins still the same numbers? – geometrikal Jan 21 '14 at 3:38
• You are correct. I was on phone and missed the 2560. They are different pins. so D13 is completely different. – mpflaga Jan 22 '14 at 2:50

I followed @mpflaga's advice and tried a different program on a different Arduino board (Pro Mini), and found that it, too, was not being read by the Bus Pirate. After a little research, I found that the Bus Pirate's fastest sniffing mode is 1MHz, while the Arduino defaults to 4MHz for SPI. I added SPI.setClockDivider(SPI_CLOCK_DIV128) to my setUp method (making the SPI clock speed 125kHz), and found that the Bus Pirate could see the data from the Arduino just fine.

From there, I worked backwards to my original setup on the Arduino Mega at 4MHz and found that everything worked. I believe what I was doing wrong is I had accidentally attached the SPI bus to the ICMP2 headers near the pin 13 LED, instead of ICMP1 near the reset button. Thanks, everyone, for your help, and I am sorry to have bothered you with a 'did you check your wiring diagram' problem.