Hi,
On a project I have a board with no less than 14 ADCs reading K-type Thermocouples and PT100 sensors. These are all SPI and I've been running them successfully for a year by now. For the latest revision of the board, we're using the T4.1 instead of T3.6 that we've used until now and judging by the number of posts on the forum, there are indeed a few things not yet discovered when it comes to SPI.
In my case, code that worked stopped working at completely random intervals (but within a few seconds). It's not the sensor stopping working, it's a hard crash of the IMXRT1060 chip itself that stops code execution. I have now nailed it down to where the error must be and I have a workaround. I do however think that this is a bug that needs to be addressed in a future version of the SPI library. The SPI chip I'm using to reproduce the bug is the MAX31855. Its been our workhorse for Thermocouples for many years and it's been very stable with T3.2 and T3.6.
Reading the MAX31855 with this code will crash within a few seconds:
Reading it with this code will never crash:
The only difference is how I read back the 4 bytes using SPI.transfer. reading 4 bytes at once will crash within a few seconds, but doing 4 reads of one byte will never crash. I'm guessing this has to do with timing and the faster speed of the T4.1 and that doing this in multiple operations solves the timing issue since it's slower?
I'm posting this as a quickfix for others with a similar problem as well as a suggestion as to something to look into the next time work is done on the SPI library. I'm not able to dig further into this at the moment, but with some luck I can revisit this when I don't have such a high workload.
PS: I have JTAG ports on this board in case that can help find the culprit.
On a project I have a board with no less than 14 ADCs reading K-type Thermocouples and PT100 sensors. These are all SPI and I've been running them successfully for a year by now. For the latest revision of the board, we're using the T4.1 instead of T3.6 that we've used until now and judging by the number of posts on the forum, there are indeed a few things not yet discovered when it comes to SPI.
In my case, code that worked stopped working at completely random intervals (but within a few seconds). It's not the sensor stopping working, it's a hard crash of the IMXRT1060 chip itself that stops code execution. I have now nailed it down to where the error must be and I have a workaround. I do however think that this is a bug that needs to be addressed in a future version of the SPI library. The SPI chip I'm using to reproduce the bug is the MAX31855. Its been our workhorse for Thermocouples for many years and it's been very stable with T3.2 and T3.6.
Reading the MAX31855 with this code will crash within a few seconds:
Code:
uint32_t MAX31855::spiread32(void) {
uint8_t buf[4];
uint8_t buf2[4];
SPI.beginTransaction( SPISettings(10000000, MSBFIRST, SPI_MODE0) );
digitalWriteFast(_cs,LOW);
SPI.transfer(buf2, buf, 4);
lastDataRead = buf[0];
lastDataRead <<= 8;
lastDataRead |= buf[1];
lastDataRead <<= 8;
lastDataRead |= buf[2];
lastDataRead <<= 8;
lastDataRead |= buf[3];
digitalWriteFast(_cs,HIGH);
SPI.endTransaction();
return lastDataRead;
}
Reading it with this code will never crash:
Code:
uint32_t MAX31855::spiread32(void) {
uint8_t buf[4];
uint8_t buf2[4];
SPI.beginTransaction( SPISettings(10000000, MSBFIRST, SPI_MODE0) );
digitalWriteFast(_cs,LOW);
SPI.transfer(buf2, buf, 1);
lastDataRead = buf[0];
lastDataRead <<= 8;
SPI.transfer(buf2, buf, 1);
lastDataRead |= buf[0];
lastDataRead <<= 8;
SPI.transfer(buf2, buf, 1);
lastDataRead |= buf[0];
lastDataRead <<= 8;
SPI.transfer(buf2, buf, 1);
lastDataRead |= buf[0];
digitalWriteFast(_cs,HIGH);
SPI.endTransaction();
return lastDataRead;
}
The only difference is how I read back the 4 bytes using SPI.transfer. reading 4 bytes at once will crash within a few seconds, but doing 4 reads of one byte will never crash. I'm guessing this has to do with timing and the faster speed of the T4.1 and that doing this in multiple operations solves the timing issue since it's slower?
I'm posting this as a quickfix for others with a similar problem as well as a suggestion as to something to look into the next time work is done on the SPI library. I'm not able to dig further into this at the moment, but with some luck I can revisit this when I don't have such a high workload.
PS: I have JTAG ports on this board in case that can help find the culprit.