Go Down

Topic: Arduino Due SPI unstable (Read 503 times) previous topic - next topic

kiyoshi7

Apr 29, 2019, 07:16 pm Last Edit: Apr 29, 2019, 07:18 pm by kiyoshi7
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
Code: [Select]


#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()
{
}


ard_newbie


Good SPI design:
https://hackaday.com/2014/11/25/better-spi-bus-design/

Since the SPI protocol is super simple, you could try direct register programing instead of the library:
http://www.jaxcoder.com/Post/Index?guid=f7c0fb45-b084-45e6-b0bd-a18322df011d

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

kiyoshi7

#2
Apr 29, 2019, 08:18 pm Last Edit: Apr 29, 2019, 08:32 pm by kiyoshi7
"Good SPI design:
https://hackaday.com/2014/11/25/better-spi-bus-design/"
already done thanks though.

"Since the SPI protocol is super simple, you could try direct register programing instead of the library:
http://www.jaxcoder.com/Post/Index?guid=f7c0fb45-b084-45e6-b0bd-a18322df011d"
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);
   }

ard_newbie

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:

https://arduino.stackexchange.com/questions/26135/code-example-spi-multiple-slaves-arduino-due

kiyoshi7

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

Code: [Select]

#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.
Code: [Select]

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 http://gammon.com.au/spi 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

Code: [Select]

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?

Go Up