Hi,

I've tried to run the sht3xd sample using nRF52840DK, which is one of the boards with sample configuration overlay file, but all I get out in the logs is this:

Hi,

This email list is for upstream zephyr, not NCS, but since the sample is
available in upstream zephyr I will respond here.

"ilkka.virtanen via lists.zephyrproject.org"
<ilkka.virtanen=sensoan.com@...> writes:

Hi,

I've tried to run the sht3xd sample using nRF52840DK, which is one of the boards with sample configuration overlay file, but all I get out in the logs is this:
*** Booting Zephyr OS build v2.6.0-rc1-ncs1  ***
Could not get SHT3XD device

What I get from this log is that for some reason the system fails to
load the device driver for the sensor.

Be careful here. There is a difference between a device and a device
driver.

The device driver can be compiled into your binary correctly, but the
individual devices can fail to initialize, which is almost definitely
what is happening here.

In general, device_get_binding() returns NULL if the device
initialization function fails, or if there is no such device.

I'm relatively new to Zephyr
and I have trouble understanding how to debug the problem. Can anyone
give me pointers where to look?

Other than the driver model documentation and the driver source code,
I've been plugging my recent device model talk a lot lately:

https://www.youtube.com/watch?v=sWaxQyIgEBY

It may be useful. YMMV :)

I've built the sample using NordicConnectSDK 1.6.1 which uses Zephyr 2.6.0-rc1-ncs1
...NordicConnectSDK/1.6.1/zephyr/samples/sensor/sht3xd$ west build -b
nrf52840dk_nrf52840

Since, as you say, there is a devicetree overlay for the board you are
using here:

https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/sensor/sht3xd/boards/nrf52840dk_nrf52840.overlay

The device structure should be allocated. So I am assuming it just
failed to initialize correctly in your environment. Did you connect the
pins as described in the comments in the overlay file?

Try stepping through sht3xd_init() in your debugger to see where it
fails, or enable more verbose logs in the sensor driver using Kconfig to
see what went wrong.

Hope this helps,
Marti

Thanks.

Thank you Marti for the reply.

The problem was indeed in the connection between the nRF52840DK and the external sensor. I watched your video, it was very good and informative.

As I learned that the device will be initialized before execution is in application code, I realize we will have a problem with the driver in our own product. Our own board will have a sht31 sensor but it is behind a TCA9548A I2C switch, which means a device tree configuration like this:
&i2c0 {
  tca9548a@71 {
    sht3xd@44 {
    };
  };
};

Can I stack the drivers like this? If yes, to be able to use the available device drivers for the sensors that are behind the I2C switch, I will need to implement the tca9548a functionality to a device driver to make this work. Do you know are there any example to use as a starting point?

Thanks again,
Ilkka

Hi again Ilkka,

"ilkka.virtanen via lists.zephyrproject.org"
<ilkka.virtanen=sensoan.com@...> writes:

Thank you Marti for the reply.

The problem was indeed in the connection between the nRF52840DK and the external sensor. I watched your video, it was very good and informative.

I'm glad; thanks!

As I learned that the device will be initialized before execution is in application code, I realize we will have a problem with the driver in our own product. Our own board will have a sht31 sensor but it is behind a TCA9548A I2C switch, which means a device tree configuration like this:
&i2c0 {
tca9548a@71 ( TCA9548A@71 ) {
sht3xd@44 {
};
};
};

Can I stack the drivers like this?

Yes, you can, you just need to make sure the initialization priorities
are managed correctly so the init functions run in the following order:

i2c0 -> tca9548a -> sht3xd

You can control the initialization priorities with Kconfig options, but
the defaults should be OK for your use case.

See CONFIG_I2C_INIT_PRIORITY and CONFIG_SENSOR_INIT_PRIORITY
respectively for i2c0 and sht3xd.

If yes, to be able to use the available device drivers for the sensors
that are behind the I2C switch, I will need to implement the tca9548a
functionality to a device driver to make this work. Do you know are
there any example to use as a starting point?

I recently reviewed a TCA9546A driver, which seems similar to your
TCA9548A.

https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/i2c/i2c_tca9546a.c

https://docs.zephyrproject.org/latest/reference/devicetree/bindings/i2c/ti%2Ctca9546a.html#dtbinding-ti-tca9546a

If the differences are superficial you may be able to extend the driver
to support "TCA954xA", i.e. both devices.

You may wish to contact the driver author if you want to collaborate.

Thanks again,
Ilkka

HTH,
Marti