Arduino Due SPI unstable

Hardware Arduino Due
1

Hi, I'm trying to get spi communication to work on my due, but I am getting some unexpected results. I know how to use SPI on the Uno, Nano and Mega board but somethings happening to the Due. I connected a logic analyzer to the spi header (except for the 5v pin) and told the due to send 0xAA. I tried using the old API (https://www.arduino.cc/en/Reference/DueExtendedSPI) and the new API (https://www.arduino.cc/en/Tutorial/SPITransaction), but both yield different and wrong results. When I use the new API the due lowers the CS for one clock cycle. When I use the old API the due sends for bits then raises the CS. What am I doing wrong?

this is basically the code I am using

#include <SPI.h>
// The setup() function runs once each time the micro-controller starts
void setup()
{
	//Initialize serial and wait for port to open:
	Serial.begin(9600);
	while (!Serial) {
		; // wait for serial port to connect. Needed for native USB
	}
	/*
	test area
	*//*
	SPI.begin(52);         // SPI Module 'wake up'
	SPI.setClockDivider(52, SPI_CLOCK_DIV128 );
	SPI.setDataMode(52, SPI_MODE0);
	SPI.setBitOrder(52, MSBFIRST);
	delay(200);          // SPI delay for initialization
	*/
	SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE0)); // SPI setup SPI communication
	SPI.begin(52);
	
	while (true)
	{
		SPI.transfer(52, 0xAA, SPI_LAST);
		delay(20);
	}
}

void loop()
{
}
2

Good SPI design:

Since the SPI protocol is super simple, you could try direct register programing instead of the library:

Furthermore, sometimes there are issues with a bad SPI MODE selection: you have only 4 MODEs to try before finding the right one....

3

"Good SPI design:
Better SPI Bus Design | Hackaday"
already done thanks though.

"Since the SPI protocol is super simple, you could try direct register programing instead of the library:
Index - JaxCoder"
If I have to do that I might as well abandon Arduino, for me this would defeat the purpose of the platform.

but why does this code work on the 8 bit ucontrollers and not on the Due?

"Furthermore, sometimes there are issues with a bad SPI MODE selection: you have only 4 MODEs to try before finding the right one...."

the problem with the due is by far more basic than that as in it is not transmitting 8 bits but 4 or one bit with code(below) that runs on a Uno and Nano with no problems. Simply put the code works just not on a due and the only thing in the system that changes is the the board(nano to due)

SPI.beginTransaction(SPISettings(500000, MSBFIRST, SPI_MODE0));
delay(200);
SPI.begin();

while (true)
{
SPI.transfer(0xAA);
delay(20);
}

4

Why do you select SPI_LAST since you transfer again and again 0xAA ?

Anyway you want first to fully understand the SPI protocol before using it on a DUE. jaxcoder.com tutorial provides a relevant information for that. The main point with SPI is that an SPI Master has to send something ( a Dummy if this is not processed by the SPI Slave) to receive something ( a Dummy if this is not processed by the SPI Master), and so on ....

Plus see this thread:

5

thanks, I got the code from the site copy and pasted it into. it looks like this:

#include <SPI.h>
// The setup() function runs once each time the micro-controller starts
void setup()
{
	SPI.begin(10);
	SPI.begin(4);
	while (true)
	{
		// Receive using pin 10 as SS
		byte byteFromTen = SPI.transfer(10, 0x00);
		// Transmit 123 using pin 10 as SS
		SPI.transfer(10, 123);
		// Both directions:
		byte otherByteFromTen = SPI.transfer(10, 123);

		// Receive using pin 4 as SS
		byte byteFromFour = SPI.transfer(4, 0x00);
		// Transmit 123 using pin 4 as SS
		SPI.transfer(4, 123);
		// Both directions:
		byte otherByteFromFour = SPI.transfer(4, 123);
	}

}

here is the code from the site, I dont see any significant changes other then putting part of the code in a loop and fixing the last line of the code.

void setup() {
    SPI.begin(10);
    SPI.begin(4);
}

void loop() {
    // Receive using pin 10 as SS
    byte byteFromTen = SPI.transfer(10, 0x00);
    // Transmit 123 using pin 10 as SS
    SPI.transfer(10, 123);
    // Both directions:
    byte otherByteFromTen = SPI.transfer(10, 123);

    // Receive using pin 4 as SS
    byte byteFromFour = SPI.transfer(4, 0x00);
    // Transmit 123 using pin 4 as SS
    SPI.transfer(4, 123);
    // Both directions:
    byte otherByteFromFour = SPI.transfer(4, 123);  // original otherByteFromTen 
}

according to this site Gammon Forum : Electronics : Microprocessors : SPI - Serial Peripheral Interface - for Arduino the default mode is mode0, I dont care right now if it is LSB first or MSB first because I have a stability issue. I am looking for two things: 1. if it outputs the same code 2. If the waveform is consistent with the code and the stability of the clock signal.

for the first item I get this from the logic analyzer. MISO is connected to 3v3 cause I dont care abot it and it cannot affect the mosi

Time [s]	 Analyzer Name	 Decoded Protocol Result
0.000004 	SPI	MOSI: 0x6E;  MISO: 0xFF
0.00007	SPI	MOSI: 0x59;  MISO: 0xFF
0.000118	SPI	MOSI: 0x22;  MISO: 0xFF
0.000178	SPI	MOSI: 0xD2;  MISO: 0xFF
0.000238	SPI	MOSI: 0xDD;  MISO: 0xFF
0.000308	SPI	MOSI: 0x77;  MISO: 0xFF
0.000374	SPI	MOSI: 0x95;  MISO: 0xFF
0.000416	SPI	MOSI: 0x4A;  MISO: 0xFF
0.00046	SPI	MOSI: 0x81;  MISO: 0xFF
0.00052	SPI	MOSI: 0xB2;  MISO: 0xFF
0.00059	SPI	MOSI: 0x7B;  MISO: 0xFF
0.00065	SPI	MOSI: 0xDD;  MISO: 0xFF
0.00072	SPI	MOSI: 0xB2;  MISO: 0xFF
0.000768	SPI	MOSI: 0xBC;  MISO: 0xFF

Two of the four transmits are supposed to be 0x00 so something is wrong and either the code or the arduino itself.

The waveform confirms what the logic analyzer is giving me and the clock signal is unstable, the pulses vary from 8us to 2us. WIRING IS NOT AN ISSUE.

Instead of giving me sites can you help by pointing to where the error is?