Trouble Access Mallow Board Temp Sensor With i2c

I am trying to access the temperature sensor that is called out in the Mallow board datasheet. I’ve been getting errors when trying to access it from my python script and when using the i2cdetect it doesn’t appear to be in the location called out on the datasheet.

root@machinepulse-15207040:/dev# i2cdetect -y 1
Warning: Can't use SMBus Quick Write command, will skip some addresses
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:
10:
20:
30: -- -- -- -- -- -- -- --
40:
50: -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- --
60:
70:

I know there are some temperature sensors on other devices from Toradex that are called out on the datasheet, but need to be special ordered. Is that also the case with this device? I do not need the sensor on my board, I was just trying to test i2c communication.

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


:handshake:

To troubleshoot the issue with accessing the temperature sensor on the Mallow Carrier Board via I²C, follow these steps:

  1. Verify I²C Bus and Address:

    • Ensure you are using the correct I²C bus and address as specified in the Mallow Carrier Board datasheet. The output of i2cdetect -y 1 suggests you are scanning bus 1. Confirm that the temperature sensor is indeed on this bus.
  2. Check Sensor Presence:

    • The i2cdetect output shows that some addresses are marked as UU, indicating that they are in use by a driver. Ensure that the address of the temperature sensor is not among these. If it is, the sensor might already be claimed by a kernel driver.
  3. Kernel Driver:

    • If the sensor is claimed by a kernel driver, you might need to interact with it through the driver interface rather than directly via I²C commands. Check the /sys/bus/i2c/devices directory for relevant entries.
  4. Device Tree Configuration:

    • Ensure that the device tree is correctly configured to enable the I²C bus and the temperature sensor. Incorrect or missing device tree entries can prevent the sensor from being detected.
  5. Hardware Connections:

    • Verify the physical connections of the I²C bus and the sensor. Ensure that the sensor is properly connected and powered.
  6. Testing with I²C Tools:

    • Use i2cdetect, i2cdump, and i2cget to further investigate the I²C bus and sensor. These tools can help you read and write to the I²C bus to verify communication.
  7. Python Script:

    • Ensure your Python script is correctly configured to access the I²C bus. Use the smbus or smbus2 library to interact with the I²C bus. Here is a basic example of how to use smbus2:

      import smbus2
      import time
      
      # Initialize I2C bus
      bus = smbus2.SMBus(1)
      
      # I2C address of the temperature sensor
      sensor_address = 0x48  # Replace with the actual address
      
      try:
          # Read temperature data
          temp_data = bus.read_byte_data(sensor_address, 0x00)  # Replace 0

Hey @dleberfinger,

Can I ask the output from cat /proc/device-tree/model I’m looking to verify that you have the mallow carrier board device tree file included.

To actually use the driver’s sysfs interface, the recommended approach would be to mount the /sys/bus/i2c/devices/1-004f/hwmon/hwmon2/temp1_input interface and read this file.

-Eric

Here is the output:
Toradex Verdin AM62 WB on Verdin Development Board

I haven’t had a chance to do anymore testing on this lately. I am able to read the temperature using the method you described above.

The main motivation here for me was that I will be getting a Temperature and Humidity sensor that I intend to install on my board and communicate via i2c and wanted to use the on board sensor for some testing before I ordered the sensor I intend to use.

Also, a slightly unrelated question, I seem to be having a bit of a hard time determining what the pin out is on the Mallow Board for the extension headers. I’m not seeing a layout that actually allows me to easily determine which part of the header is which pin. This seems like a pretty trivial bit of knowledge, but I seem unable to find it.

Hey @dleberfinger,

I believe the reason you do not see the temperature device with i2cdetect is because the driver responsible indicates a system use, thus why under /sys/ we can get values.

There is a physical white dot on the carrier board connector that represents the first pin. From the perspective of the first pin, the rest follows such like:

(1) * * (2)
(3) * * (4)
(5) * * (6)
(7) * * (8)

-Eric

1 Like

@eric.tx

I’m back at this and have a sample temperature/humidity sensor. I am still struggling to detect any sensors on the i2c bus. The image below shows the blanks, dashes, UU. Are the blank spaces unusable?

image

I am testing with this sensor, linked below, which requires 5V power. That has me a little concerned and may be causing my issues as the mallow/verdin only support 1.8V i2c, but I’m not certain what voltage my i2c is. With 5V on my sensor, I get no voltage out of the i2c lines.

Any help here would be greatly appreciated.

Hey @dleberfinger,

The sensor you have linked has a reference to the datasheet. On that datasheet (page 5/11) It states

 "The sensor cannot be addressed by I2C protocol; however, the sensor can be connected to an I2C bus without interference with other devices connected to the bus. The controller must
switch between the protocols"

So it sounds like the sensor itself uses some protocol other than I2C. But on the wiki page it references I2C. Searching through the Linux kernel, I found …/drivers/hwmon/sht3.x, which states "The SHT3X comes in many different versions, this driver is for the I2C version only)."
It’s not clear which one you have, so you may just need to try and find out. Have you added this hardware component to your I2C node in the device tree? Can you share what you have.

And also important on voltage:

On that datasheet page it references the output voltages are dependent on the input voltages, and an output high is 90-100% of VDD. So you would need some voltage logic level converted to get to the correct 1.8v.

-Eric