Using the LTC2984 Demo Circuit 2399A with the 2211A daughter board. Connected are a 44007 thermistor between J2 pins 2 and 3, J2 pins 1 and 2 shorted, J2 pins 3 and 5 shorted. Configured to use the 2K resistor connected to CH1 and CH2 on the 2211A as my sense resistor by writing 0xE81F4000 to address 0x204. Configured CH4 for the thermistor by writing 0xA8860000 to address 0x20C which should indicate a type 44007 thermistor, sense channel 2, differential no share no rotate and auto range excitation current.
I write 0x84 to address 0 to start the conversion. I then read 0x44 from address 0, indicating that the conversion is DONE. I read starting at address 0x1C : 0xFF, F0, 64, 00. Which does not make any sense. All fault bits are set in addition to the VALID bit. The temperature value is -999C. If I read the 4 bytes starting from address 0x1C before trying a conversion, I see all 00s so my readings are not stale data.
Have tried several other combinations with thermistors but always get 0xFFF06400 for the results.
The LTC2984 Demo board is connected to an Atmel Xmega MCU, communicating over the SPI at 2 MHz and providing 3.3V. SPI communication is reliable.
What condition would cause the LTC2984 to set the VALID and ERROR bits at the same time. Must be clue to something.
Any ideas on what I'm missing?
We're taking a look. For reference, the valid bit is a little bit of a misnomer - it just means that data has been written out to the results register from the linearization engine - since the results space is user-writeable you could check that new results are written (say for a multi-conversion mask operation) by zeroing them out and then checking the valid bit. Doesn't really mean the data is good, it will always be set if the linearization logic finishes.
All 1's in the status byte typically indicates a configuration error. I looked at your register settings and everything looks good, as does your description of the wiring (jumper and thermistor position). I'm away from the lab at the moment but have asked a couple folks to take a look.
How long are you waiting before reading the results or the command status register (seeing 0x44?). Auto-ranging is a three-cycle measurement so the INT signal should be low for about 250ms.
Also, can you confirm you bring CSn high after each transaction?
We couldn't find any issues with the values you are writing to the LTC2984 for this configuration.
Can you verify they can be read back? You seem to be reading results just fine, so we're wondering if somehow the configuration data isn't getting written to the part correctly.
To verify, you are not using the EEPROM correct?
Also, if you have a Linduino please download the TestBench GUI (Demo Software) here:
Even without the Linduino it may be worthwhile to download the demo software as it can generate an Arduino-compatible C code project for a given configuration.
CS is going high after SPI activity.
INT only stays low for 2.2ms after the start of conversion on the channel that I've configured. If I start a conversion on a channel that has not been configured it also stays low for 2.2ms and gives the same results. It suggests that the part does not like the configuration but what is wrong??? Anything else that needs to written other than the higher channel that has the sensor and the higher channel that has the sense resistor? Some global bit somewhere maybe??
Not using the EEPROM.
I can read back the configuration data that I've written, looks OK.
The results can be cleared to all 0s and the new result will be the same.
I've looked at the Linduino code and the configuration values appear the same as I have.
More info. Hooked up the Linduino board and it works. Scoped out the SPI signals. The exact same values are written to the active registers as I was writing. All the other registers, which default to 0, are written to 0, addresses 0xf0 and 0xff are written twice, first before writing to the other configuration registers and then after writing to them, just before starting the conversion. This shouldn't matter, but does it??
The SPI timing is strange, there is about a 300 us delay from CS asserted low to the first byte starts clocking, after each byte is clocked in there is about another 300 us before the next byte or CS is set high. The SPI clock is 1 MHz. According to the data sheet it requires only 100 ns from CS to CLK and no delay is specified between bytes. Is noted. Could this make a difference??
Found the problem, it was a bug in my SPI code, address bits above bit 7 were wrong so the config data was not being written properly. Since the bug affected both read and write I could read back the data (from the same wrong address). Looks to be working OK now.
Sorry the problem, but thanks for your help.