Go Down

Topic: Due SPI uses wrong mode?! (Read 247 times) previous topic - next topic

AdderD

So, I have sketches with this line in them:
SPISettings canSPISettings(1000000, MSBFIRST, SPI_MODE0);

Before SPI is accessed the proper beginTransaction is used:

Code: [Select]

void MCP2515::Reset() {
  SPI.beginTransaction(canSPISettings);
  digitalWrite(_CS,LOW);
  SPI.transfer(CAN_RESET);
  digitalWrite(_CS,HIGH);
  SPI.endTransaction();
}


The problem is, quite often it does not seem to actually use mode 0! If I scope the traffic with a Saleae Logic I find that gibberish is being sent on the bus. However, if I go into the SPI settings in Logic and set CPOL=1, CPHA=1 (Mode 3) then all of the traffic is interpreted properly. This leads me to believe that the Due somehow used mode 3 for SPI traffic in that transaction even though I very plainly asked for mode 0. Has anyone seen something like this before?!

ard_newbie

#1
Nov 14, 2017, 07:48 am Last Edit: Nov 14, 2017, 07:50 am by ard_newbie
There may be some confusion in SPI Mode: If you look at Table 32-4 page 680 of Sam3x datasheet, you will see :

Mode     CPOL  NCPHA
  Mode0   0   1
  Mode1   0   0
  Mode2   1   1
  Mode3   1   0

IMO the SPI mode number is only a convention, it may differ from a device to another one.

I only use direct port programming, either with the SPI controller or USART0/USART1 in SPI mode. This way I know exactly what's going on.

Once you know what your sensor is waiting for in terms of CPOL/NCPHA, the SPI setting becomes straightforward.

david_prentice

Surely you set the mode number in the Settings object.
How the Due or any other target sets the low level hardware is not your concern.

Untested.   I am on a Tablet.    I would guess that if beginTransaction() did not work on a Due,   people would have whinged about it years ago.

David.

weird_dave

Can you post a pic of the gibberish? a single byte transaction would be preferable, including the /CS.

AdderD

Well, it doesn't seem to be happening at the moment. I found that perhaps I hadn't controlled CS quite well enough and also in Logic I wasn't reading the enable pin. Somewhere between those two things it seems the capture went wonky and it'd always think that the mode was wrong. But, maybe it never was. Never mind then,

david_prentice

The Saleae SPI decoder starts with the CS transition.   It expects a valid SCK level according to mode.

In practice,  you can't capture SPI any faster than 12MHz.    I always reduce SPI speeds before tracing with Logic-8.  The newer Saleae can go a little faster.

The Arduino Transaction Settings are very useful for slowing SPI during the program development stage.

David.

Go Up