With hardware SPI, failure check doesn't work

[Saur0o0n]

Hi,

On esp32 (1.0.4+ framework) with hardware SPI, if MAX31855 is disconnected (or failed), library will output 0.0 value - not NAN and failure. This is true for both, old release without Adafruit_SPIDevice and with it.

Just compile library on empty esp32 board and use hw SPI in serial example.
Output:

MAX31855 test
Internal Temp = 0.00
C = 0.00
Internal Temp = 0.00
C = 0.00
Internal Temp = 0.00
C = 0.00

And there should be an error reported like with software spi is.

[ladyada]

please try master branch for speed reduction. if reading is 0's there's no error to report - errors come in when the value is not 0 (not so great but this is the chip behavior)

[Saur0o0n]

Hi,
Even if I try

Adafruit_MAX31855::Adafruit_MAX31855(int8_t _cs) {
  spi_dev = Adafruit_SPIDevice(_cs, 10000);

so much lower values, this still reports 0x0. Is there a way, during normal operation, that MAX31855 can report back 0x0 (there are bit's with some intermal max stuff, two temperatures etc.) - isn't it's just safe to assume value 0x0 is incorrect the same way 0xFFFFFF is?
This is what I did, for now in my project.

Why readCelcius is sanitized (checked against 0xF) and readInternal not?

[ladyada]

you can read the datasheet to see what error bits there are we just tried it with a esp32 and it worked for us?

[tablatronix]

I think I know what OP is talking about , let me check my notes to be certain but I am fairly sure, there is a time when no error codes are thrown, I think it is because the default memory spits out all 0s and it sees no error. eg, spiread32 returns 0, even if comm fails( or is not actually occurring )

It could be fixable to make sure the lib is actually getting data , by setting the reserved bits to 1 and making sure they are changed to 0. D3 and D17 should always be 0, D16 could also be checked against the 3 fault bits, to make sure they are properly set

TLDR, there is no error catch for no actual data being returned, all 0 bits

I know in i2c endtransmission returns data status, I have no idea how SPI ack works if it even exists..

[ladyada]

yeah theres no way to know if SPI devices are connected. reserved bits...shouldn't be set :/

[tablatronix]

I mean in an incoming data mask, not to device, to check they are cleared by device.

[tablatronix]

Yeah that is probably not going to work if 'SO' just stays low.. a-doy my bad , So how do you use something like this when there is no high bit anywhere and its valid data, and no checksum either...

[tablatronix]

I am messing with these atm, I will play with it a bit and see what exactly I was seeing last time In observed this.

[tablatronix]

@Saur0o0n are you using another spi device and or library in your code?

I found the issue with mine is that even when using spi transactions in the max library, if the other libraries leave the (on esp8266) SPI1U register in write mode, and not SPIUDUPLEX bit set, then spi.transfer fails to read.

If you call spi.begin() or set that before reading the max it works. Not sure exactly why, I have not looked into the transfer method.

There is no issue with the max chip it is getting its cs and clock and outputing its bitstream just fine, but spi is not reading it in at all and just returning 0xFFFFFFF to this library.

To test in spiread32 method
call begin(); always and see if it changes.

uint32_t Adafruit_MAX31855::spiread32(void) {
  int i;
  uint32_t d = 0;
  uint8_t buf[4];

  // backcompatibility!
  if (!initialized) {
    begin();
  }
  
 begin(); // <---
  spi_dev.read(buf, 4);

...

  Serial.println(SPI1U,HEX);
  SPI1U = SPIUMOSI | SPIUDUPLEX | SPIUSSE; // this is in spi.begin()

Ideally if your other libraries support transactions, enable it

[Saur0o0n]

Hi,
Well I was using more SPI devices on different HW SPI on esp32 - one HW SPI was dedicated to max31855 (two of them), And that's why I've introduced patch to use other object then just default "spi". Anyway, now I've switched to another library, since it was easier to debug and modify it.