Hello,
Did anyone already observe such strange behavior ?
We reproduced it (scope traces) on both the DevKit and on our LATOURNETT board…
Best regards,
Sylvain
Hello,
I had a quick look at the source code of Pigeon Point but cannot see how this could happen.
Best regards,
Markus
Hello Sylvain,
just saw the scope traces, I think you’re using the function wrong, the last argument gives the number of bytes to transfer, this should be at least 1, probably 2 in the case of the TMP464, since it has 16 bit registers.
cheers,
Stefan
Hello,
We of course already tried all those possibilities without success…
Cheers,
Hello Sylvain,
I had another look at the scope traces and they do in fact make sense. The bits are:
START(0) 0 1 0 0 1 0 0 W(0) NACK(1) STOP(0)
So it is a write cycle as expected, however there is no ACK from the slave since the address is wrong. You need to pass the 8-bit address to the function, i.e. 0x290. I’m afraid this is often causing confusion with I2C devices, since some vendors specify 7-bit addresses and other 8-bit addresses. We should spell this out clearly in the sensor driver documentation.
Can you please try with 0x290 and see if it works?
cheers,
Stefan
Sadly this is it…
Best regards,
Hi Sylvain,
Does this mean that you can do the read now OK?
I would not call that “sad” – so it is a success! 
Cheers,
ralf.
Hi Ralf,
Sorry, but several months lost just to succeed at one i2c read is not such a great achievement according to me…
But thank you anyway !
Cheers,
Sylvain
Hi Sylvain,
I am really sorry to hear about the time lost.
We will add a warning on the I2C addressing issue. If it helps we could also add pointers to the I2C documentation; there are also some pretty good tutorials on the web.
Cheers,
Ralf.