BeagleBone Black: MCP9600 thermocouple temperature convertor: I2C clock stretching issue

Dear friends, I’m trying to use the mikro-e Thermo K Click, a break out board with Microchip’s MCP9600 thermocouple convertor, with the BeagleBone Black. It is connected by I2C and supports a clock frequency of up to 100 kHz.

In order to read a measurement from the MCP9600 (at the I2C address 0x67), six bytes of data have to be read from its register 0x00 on:

BBB_Query_20190618_GutfallMitStretching.png

As specified in the MCP9600’s data sheet, clock stretching occurs after each transmitted byte.

More than 90% of all queries yield non-sense values because clock stretching after some bytes is missed and the previous one seems to be repeated then, which looks like this:

BBB_Query_20190618_SchlechtfallTlwOhneStretching.png

Do you have any idea what is going wrong there? I believed the BBB to support clock stretching, and now I’m wondering if that is really the problem.

Thank you for your help in advance.

Did you ever get any resolution on this? The hardware/driver should support clock stretching, but I’ve started running into an issue where it doesn’t seem to be reporting the support properly–though I could be dealing with an issue with a incompletely back-ported driver. It made me curious if you ever found your issue.

BBB_Query_20190618_GutfallMitStretching.png

BBB_Query_20190618_SchlechtfallTlwOhneStretching.png

Jason:

What happens when you reading the device with the i2cdump utility? This has a mode setting to control whether it reads bytes (8 bits) or words (16 bits) at a time. For example:

i2cdump -y 2 0x67 b

Should dump the entire contents of the MCP9600 registers as bytes.

There’s a man page that gives all the options.

I found this command useful when troubleshooting my own i2c devices. If i2cdump works properly, that would seem to indicate a driver issue. If it doesn’t work, then it’s something else.

-Steve