Arduino M0 SPI Clock has extra long initial pulse on startup.

Using Arduino Networking, Protocols, and Devices
#1

Hi,

I have an application using an Arduino M0, MAX31855 Thermocouple board, and a SD Card board, and a number of external digital input interrupts.

On startup the SPI clock starts with an extra long pulse then the “normal” 16 pulses (readings) The effect is to shift the read bits to the left by 1 digit.

I would not ordinarily worry about the 1st reading on startup but I’ve seen the same phenomenon when the Digital I/O interrupt receives a lot of pulses. I am hoping if I can understand the startup situation it will give me a better understanding of the issue when the I/O interrupts (perhaps too many times).

I’ve already disabled interrupts when the SPI is reading the thermocouple board, no help.

Can anyone suggest where to look? Or perhaps others have run across this issue.

// *** Setup  ****************************************************************
// ***************************************************************************

void setup() {
 //noInterrupts();
 init_pins_int();

   SerialUSB.begin(115200);
 delay(2000);


 Wire.begin();
 Wire.setClock(400000L);

// 3) init Type K  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 3
   SPI.begin();  // not sure if this is needed for SD card?
   SerialUSB.println("...trigger now..");
   delay(2500);
   ReadRawTemperature();    <----------------- measurement is from this line //

// 1) Init SD Card  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 1
 initSD_Card();

// 4) init RTC  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 4
   init_RTC();

// 5) init OLED <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 4
   oled.begin(&Adafruit128x32, OLED_ADDRESS);
 OLED_Init();

// 6) Write Date-Time to SD Card with heading text <<<<< 5
 LogRTCdate_time();

.
.
.
.
.
.
.
// ************************************************************
// *** Type K functions ***************************************
// ************************************************************

uint16_t ReadRawTemperature(void)
{
 int16_t _rawData = 0;
 digitalWrite(TK_CSPin, LOW);       //stop  measurement/conversion
 delayMicroseconds(10);
 digitalWrite(TK_CSPin, HIGH);      //start new measurement/conversion
 delay(110);
 noInterrupts();   // stop Furnace isr from interrupting reading
   // might delay / miss a furnace change.
 digitalWrite(TK_CSPin, LOW);       //set CS low to read SPI interface

   SPI.beginTransaction(SPISettings(1000000, MSBFIRST, SPI_MODE0));
   _rawData = SPI.transfer16(0x0000);   // TypeK is read only, doesn't matter what is sent in SPI.transfer16(0x000)
   SPI.endTransaction();
   digitalWrite(TK_CSPin, HIGH);    //deselect Type K, let it convert for next read.
   if (_rawData & 0b01) TypeK_Error = true;
   interrupts();
   return _rawData;
}

Looking at the attachment you can see the long pulse (Red) that should not exist. And the last “unused” pulse that would normally be the last bit.

I’ve added the image to the post but you may have to download it to see the details…sorry.

Thanks

John

clock.jpg
clock.jpg1510×191 34 KB

#2

For those who might be interested.

I’ve determined the root cause of the extra (long) pulse on the SPI clock but I think I’ve been able to eliminate its occurrence.

Symptom: When reading a MAX31855 breakout board (SPI) an extra clock pulse was sent by the SAMD21. This occurred when a number of interrupts happened just prior to the SPI read. It extra pulse does not occur when the SerialUSB is not being used and not initiated.

Before removing the SerialUSB I tried disabling the External interrupts just prior to reading the MAX board. Had no effect on the issue.

It turns out the order of the CS and The “SPI.beginTransaction” is critical. Unintuitively, the CS must occur “AFTER” the SPI.beginTransaction statement. This essentially starts reading the device after the above mentioned long pulse has occurred. Thanks to Bill Greiman for his help with this.

SPI.beginTransaction(SPISettings(TypeKsettings));
  digitalWrite(TK_CSPin, LOW);
  _rawData = SPI.transfer16(0x0011); //read MSB only
   digitalWrite(TK_CSPin, HIGH);
  SPI.endTransaction();

John

#3