T4 SPI mode0 transmit bug?

Status
Not open for further replies.

DougMcK

Well-known member
Greetings!

I've been diving into SPI recently and I wonder if I may have found a bug with the SPI library as implemented for the T4? In SPI mode 0 the data are sampled on the rising edge of the clock. So, data transitions coincident with the clock's rising edge may or may not work depending on the exact details of the edges, and that shouldn't be allowed.

I noticed that SPI mode 0 writes looked odd on the T4, so I compiled and ran the code below on both the T4 and T3.6 (Teensyduino 1.49). The 'scope traces show that the first rising clock edge is coincident with a data transition for the T4, but the T3.6 looks good.

In both 'scope images chip select is pink, clock is yellow, and data is blue. Note that the data transitions coincident with the first clock edge on the first image (T4). Is this a bug, or am I missing something?

cheers,
Doug


Code:
#include "SPI.h"
uint8_t payload=0;

void setup()
{
  Serial.begin(115200);
  delay(5000);
  pinMode(10, OUTPUT);
  SPI.begin();
}

void loop()
{
  SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE0));
  digitalWriteFast(10, LOW);
  Serial.println(SPI.transfer(payload));
  Serial.println(payload);
  payload++;
  digitalWriteFast(10, HIGH);
  SPI.endTransaction();
  delay(2000);
}
 

Attachments

  • DS0001.PNG
    DS0001.PNG
    20.4 KB · Views: 101
  • DS0002.PNG
    DS0002.PNG
    20.9 KB · Views: 110
Yes, this does not look OK.
Might be needed to have look at the registers if there is a way to fix this.
 
Hm, but I can't confirm this:

pic_31_1.png
(clk yellow, data cyan)

My code is more simple:
Code:
#include "SPI.h"

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

void loop()
{
  SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE0));
  SPI.transfer(0x80);
  SPI.endTransaction();
}
It is a "perfect" Mode 0 - Data valid at rising edge of clk (cpol=0, cpha=0)


arduino_fullduplex_spi_tranmission.png
 
Yikes! While that might work ok in many environments it looks to me like it's being timed from the wrong edge...
 
I was just looking at the NXP MK66 datasheet, because I'm really more focused on the T3.6 SPI interface for now. The spec for data setup time is 15.8nS, so that timing shown in your figure is right on the edge, even for a Teensy 3.6.

So I reckon this is something that should be fixed. My skills are lacking in this domain, or I'd go poking around myself.
cheers,
Doug
 
maybe yes...
not sure what this does in your case, tonton, but if the change above does not help, you can try to add this (line 1208):
Code:
            _ccr = LPSPI_CCR_SCKDIV(div) | LPSPI_CCR_DBT(div/2)[COLOR=#ff0000] | LPSPI_CCR_PCSSCK(div/2) | LPSPI_CCR_SCKPCS(div/2)[/COLOR];
It looks like yor're not using the hardware-chipselect but the PCSSCK seems to influence the time nevertheless - perhaps SCKPCS does the same? I've not tested this.

Edit: Yes, on the scope it looks better.
 
Frank, yes, I agree it looks correct now in my testing too. I'm not really using T4 SPI, but I'm glad my observation may have helped you fix something.
Thanks very much,
Doug
 
Status
Not open for further replies.
Back
Top