Invalid pointer value in LM75AD sensor ?

[saurabhsaxena]

Hello,

         I have been implementing I2C using the bit banging, during the implementation phase where I was implementing the collision detection on the bus I came across an issue, the sensor generates a ACK for the pointer byte 0xFF which a invalid pointer.

My scenario :

To test my code I inserted the additional SCLK pulse after passing the whole address to the sensor(before R/W and ACK), this additional SCLK pulse cause the sensor to sample A0 two times, one time as address and other time as the R/W , the Slaves runs ahead of the master now. As A0 is zero in my case this causes the Sensor to assume a Write operation.

Using the Bus detection, I sense the inconsistency at the part of Read operation on the Bus but the Slave pulls the SDA line low as its a step ahead and generates a ACK.

As I have sensed the inconsistency I try to recover the bus by sending nine clock pulse (SDA open), but as the Sensor though my operation in write state is took this as a pointer byte  which was sent 0xFF and generates a ACK.

My question the LM75AD datasheet doesn't enlist 0xFF as a valid pointer location than how come the sensor is generating a ACK. please help if I got it right.

[david_diaz]

Hello,

I2C slaves work as a state machine. After they have been addressed they keep receiving bytes until they see another start condition or a stop condition send by the I2C bus master.

The LM75A slave address on the I2C-bus is partially defined by the logic applied to the device address pins A2, A1 and A0 as below:

So, the 0xFF Is not a valid address for the device.

In this case, a waveform of the I2C communication would be useful. Can you please share it?

Finally, please make sure you are within the parameters mentioned on Table 18 from the datasheet.

Regards,

David

[saurabhsaxena]

Hi David,

Actually I am passing valid address to the sensor, the problem is that I am trying to provide Bus recovery support in case my S/W implemented I2c peripheral code fails(Bit-banged).

In my case the sensor address is passed and then during the write operation, when passing the pointer byte to the sensor, which is passed as 0xFF(Not a valid pointer byte according the datasheet) to the sensor, the sensor generates a ACK.

Why is sensor generating ACK for invalid pointer byte?

Description

I have implemented the I2C interface on an C51 architecture(S/W) along with bus stuck recovery. To test the logic I inserted additional clock after passing the A0 (address bit) to the sensor i.e before writing the R/W bit on the bus,

this causes the sensor to sample the A0 bit which is zero in my case two time.

This makes the Sensor run a clock ahead, which now generated a ACK on the R/W (Though I want to read --> 1 but senor pulls the bus low --> 0 ) makes the bus zero (AND bus logic) and then master waits for ACK in the next cycle leaves the bus for the slave to drive, but as the slave is in write mode a clock pulse ahead as it sampled A0 two times, it thinks that the Master is writing the pointer Byte.

My code as it doesn't receive the ACK on the ninth pulse now run bus recovery( provides Clock), but as the sensor was in write mode this causes to pass a pointer byte on bus as 0xFF, but the mystery here is that though the sensor datasheet doesn't enlist 0xFF as valid pointer data byte it generates a ACK for that.

Can you please tell me why ACK is generated while writing a 0xFF as pointer byte?

I will post the wave form soon.

[saurabhsaxena]

Hi David,

Please find below the give waveform, here we are performing a write operation A0-A2 are all zero, the bus is left open and sensor samples the pointer address during the time and a ACK can be seen on the 19th Clock.

I hope this helps this is the best I can get now, its clear during the 19th clock the bus is grounded by Sensor as ACK.

I have lost my old DSO, hope it helps.