Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

With hardware SPI, failure check doesn't work #37

Closed
Saur0o0n opened this issue Feb 22, 2020 · 10 comments
Closed

With hardware SPI, failure check doesn't work #37

Saur0o0n opened this issue Feb 22, 2020 · 10 comments

Comments

@Saur0o0n
Copy link

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
Copy link
Member

ladyada commented Feb 22, 2020

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
Copy link
Author

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
Copy link
Member

ladyada commented Feb 22, 2020

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
Copy link

tablatronix commented Mar 25, 2020

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
Copy link
Member

ladyada commented Mar 25, 2020

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

@tablatronix
Copy link

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

@tablatronix
Copy link

tablatronix commented Mar 25, 2020

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
Copy link

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
Copy link

tablatronix commented Apr 3, 2020

@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
Copy link
Author

Saur0o0n commented Apr 3, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants