I2C Read Error - MLX90640 Thermal Sensor

I’m making use of the MLX90640 thermal sensor array. It’s a sensor that’s used as thermal camera on a low resolution (Error - Melexis). I’ve been working with it for the past week on a Raspberry Pi 3B+ without any problems. However I couldn’t get it to work for the NVidia Jetson TX2. After trying numerous solutions I went back to the Pi with the same sensor and it turned out the sensor was no longer working with the same software.

Besides using the software I had written myself I tried the examples by the manufacturer (https://github.com/pimoroni/mlx90640-library) without any luck. It will either return I2C Read Error! on the Jetson or frameData timeout error waiting for dataReady in combination with a Segmentation fault on the Pi.

I can still detect the sensor with i2cdetect:

pi@raspberrypi:~/ $ sudo i2cdetect -yr 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- 33 -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --

The standard address is 0x33.

The reason I’m asking is because it is very hard to find information on the sensor or other i2c sensors having the same issue. The odd thing is that it used to work properly in the exact same situation on the Pi. Ever since I’ve been trying to get it to work on the Jetson nothing seems to work anymore. The only thing I can think of is the Jetson somehow changed the internal registers of the sensor. Any ideas are welcome as I’ve tried everything as far as I know.

Have you check if the i2cget can get data?

Thank you for replying. When running

sudo i2cget 1 0x33

I only get 0x00 in return. I’m not really sure if I can expand this command, the instructions with --help are a bit unclear to me.

sudo i2cget -f -y 1 0x33 0

1 means bus
0x33 - device id
0 - slave address.

Still returns ‘0x00’ every time I run it.

I tried two sensors in the same way and the same thing happened. Already ordered new ones but I’d like to know what could have gone wrong before I try and connect those.

You may need to probe the analysis if the device return the value as expect.

Did you ever get this Sensor to work on the Jetson TX2?

I had similar results as you where i2cdetect was able to pick it up at address 0x33, but when running any of the examples I’d get a I2C Read Error followed by Subpage 0.

I know its writing to the correct I2C bus because I see the activity on the scope. I’ll have to dive a little deeper into trying to figure out why it’s not working. I’ll probably end up getting a Raspberry PI to test it to see what’s supposed to come across.

It’s likely some compatibility issue with the i2c driver used on the Jetson.

I’m using these instructions.

Where I compile it for I2C_MODE=LINUX

Then I verify that it has the correct I2C channel by modifying line 34 on this file.

One thing that’s a bit unnerving about this sensor is it’s possible to change it’s I2C device address. The first one I tried stopped responding to i2cdetect. I did everything I could to resurrect it, but it would not work. It just wouldn’t respond to any valid I2C device address. I even desoldered it, and I put it into the EVM from Melexis and it still wouldn’t work.

So I’m trying to be a bit more careful with this one.

If I don’t get a Raspberry PI my next step will be to find a utility to write 16-bit addresses to it. You can’t use I2cget because it doesn’t support 16bit register addresses. You’ll just get back 0x00 regardless of what you try.

After trying two sensors and probably bricking them, I ordered a couple of new sensors and continued working on my project on the Raspberry Pi without any issues. I haven’t connected any of the thermophiles to the Jetson since because I’m afraid of bricking more sensors (luckily the use of the Jetson was just for RNN calculations which have been left out of the project due to time restrictions). However I’m pleased to hear from you if you ever get it to work, or find out why it didn’t. I now got three of these (possibly) bricked MLX90640’s laying around so it’d be nice if they can be brought back to life :)

My conclusion is that these sensors are quite sensitive and the Jetson probably sent some bad bytes or high voltage to the sensor somehow.

If you’re going to test on a Pi, don’t forget to alter the baudrate speed in the system preferences file.

Interesting point on the I2cget function btw, I didn’t pick that up in my research.

I tried the sensor on the Raspberry PI 4, but I’m getting the same
“frameData timeout error waiting for dataReady” in combination with a “Segmentation fault” that you’re getting.

I did change the I2C speed to 400KHz per the instructions.

My next steps are

1 → Verify the I2C speed with the scope
2 → Hook up the Sensor to the MLX90640-41 EVB board from Melexis to see how it performs on it.

I really need tech support from Melexis, but I don’t see any them having any kind of support.

I fail to see how the Jetson is messing them up since the Jetson voltage is fine, and none of the Jetson stuff gets very far. So it’s really an odd issue.

Nothing I tried enabled that Sensor to work on the Raspberry PI 4.

So then I decided to take a new approach.

Step 1 - Took the Narrow Sensor that was included in the MLX90640 EVB, and I put it in a socket wiring assembly I made. I hooked it up to the MLX90640_EVB to verify that it worked, and then I saved the contents of the EEPROM onto my computer. That way if something happened to the contents I’d have a way of possibly recovering it.

Step 2 - Removed the sensor from the EVB, and attached it to the Raspberry PI. I verified that it worked correctly using the Pimoroni mlx90640-library.

Step 3 - Tried it with a Python3 library I found (GitHub - a-kore/mlx90640-python: A python class for the use of the MLX90640 Thermal Camera), and that worked as well.

Step 4 - Powered down the Raspberry PI, and moved the Sensor over to the Jetson Nano.

Step 5 → Decided to start with the Python3 library and that surprisingly worked after changing the smbus i2c port. Surprising as it was meant for the Raspberry PI as far as I could tell.

Step 6 → Debated about whether I should quit while I’m ahead, and preserve the now working code/device or to continue on. Decided to continue on with the originally planned testing.

Step 7 → Tested the Pimoroni mlx90640-library, and that failed the same way it did before.

Step 8 → Tried the Python3 library, and it no longer worked. It gave me the dreaded framedata timeout error, and crashed.

Step 9 → Powered Down the Jetson, and moved the sensor to the Raspberry PI.

Step 10 → Tested the Pimoroni mlx90640-library, and the Python3 library. They both failed.

Now I’m going to try to figure out what changed in the EEPROM, and try to figure out how to reload the old contents to get the sensor working.

I opened an issue on the github repository, and hopefully they’ll create a notice for people not to try it on the Jetson product lineup. To prevent people from bricking their sensors.

https://github.com/pimoroni/mlx90640-library/issues/38

hi S4WRXTTCS.
finally, did you make it worked with jetson nano python ?