We are using the LM95234 and are seeing errors on reads of the Common Status Register over I2C. As a test case, we set up the Command Byte to be 0x02 and repeatedly read the Command Status Register. For successful reads, we get 0x01 returned from the Common Status Register. About once every 100k reads, we get 0XFF returned from the read from the Command Status Register, but we have not seen this problem with any other Registers in the chip.
A couple of questions:
1. Are there any known issues/errata with reading the Command Status Register reliably?
2. What does the Busy bit exactly mean in the Command Status Register? Is the Busy bit just used for polling to know when a conversion is completed or does it indicate anything else?
Hi Kenneth,
What do you mean by "Command Byte"? Are you writing to the Main Configuration Register at address 0x03 the value 0x02?
Please let me know the value of the other registers:
What values do you get back from Status Registers 1-4 at addresses 0x07 through 0x0A?
To answer your questions:
1. None that I know of for Common Status Register at 0x02 (I don't know what you mean by Command Status Register).
2. The busy bit in the Common Status Register reports when the device is converting. It can be used along with the one shot mode to see when the conversion has completed. You can pole it continuously, I am surprised you don't get other values from this register. If you are reading 0x01 that means that you have an error flag set in STATUS register 1 (Diode Fault Register). Are all the diode inputs connected?
Note: reading 0xFFh usually means that the communication was not successful and that you are just read a the bus default state of all '1's. Are you validating that the device has ACK'd the slave address? Perhaps that's where the problem lies.
Take care,
EmmyPrecision Systems ApplicationsTexas Instruments SVA
Emmy
Integrated Signal Chain ApplicationsTexas Instruments
Emmy,
The following settings are used in other registers:
Conversion Rate (0x04) is set to 0x01 = 0.364 seconds
Conversion Enable (0x05) is set to 0x03
Diode Model Select (0x30) is set to 0x0E
Filter Settings are never Changed from defaults
Register 0x40 WB_TEMP_LOCAL_TCRIT_LIM_REG is set to 0x85 Register 0x41 WB_TEMP_REM1_TCRIT1_LIM_REG is set to 0x65 Register 0x49 WB_TEMP_REM1_TCRIT2_3_LIM_REG is set to 0x85 Register/ 0x0C WB_TEMP_TCRIT1_MASK_REG is set to 0x1D Register 0x0D WB_TEMP_TCRIT2_MASK_REG is set to 0x1D Register 0x0E WB_TEMP_TCRIT3_MASK_REG is set to 0x1ERegister 0x5A WB_TEMP_TCRIT_HYST_REG is set to 0x05
We are seeing an Ack from a Slave device when the read request is sent. See the attached Scope trace.
Thanks,
Ken
The LSB of the temperatures are never read
Can you also please let us know how many 0xFF in a row you get?
In addition can you set the conversion rate register to continuous and tell us what happens?
Thanks!
Yes, we were writing the the Main Configuration Register at address 0x03 the value of 0x02.
We are only seeing isolated instances of the 0xFF and on succeeding reads it returns to reading 0x01 as it should.
I will work with the team to set the conversion rate register to continuous on Monday. Right now, we are away from the hardware.
Are there evaluation boards of the LM95234 available where the chip could be tested in isolation? We have the chip down on two different boards in our system and a fairly extensive I2C network and it is the only chip where we are seeing problems with I2C reads.
I will try to see if I can get an eval board to you. Do you have a local FAE that you usually work with. I can contact him for you to get one out to you.
BTW if you haven't made it to the lab yet, is there any way you can zoom in on a clock period as it looks like your clock rise times are really slow. Even though we have shcmidtt trigger inupts there are limitations on the rise and fall time they can handle. It's hard to tell from the scope photo you sent but you should allso check to see if any of the falling edges are marginal. That is see if the data changes state when the clock is high, as the chip would recognize this as a false start in the middle of a communication and restart searching for the device address then get off the bus with a NACK, thus you would read 0xFF. It could take 100ns overalp in the wrong direction for the chip to recognize a false start or stop.
Take care
I have conversed with one of your colleagues about this issue off line and it is now solved.