Zephyr: On missing sensor, Init hangs

[olsky]

Describe the bug
I have a custom nrf9160 board with i2c sensors. When all sensors are on the board -- init is ok, all runs.

But, if a sensor is physically not there (was removed), it hangs in init of sensor --- is not returning.
The problem is: it never enters main function, as init happens before entry into main.

Expected behavior
It would be good to set a time limit on init, so if the sensors init hangs -- the process is aborted and the normally run.

Impact
the main is never reached.

* additional info *
the problem is with the init of SCC811 sensor, on another board the LIS2DH is missing, but the init is returned with an error and all goes fine.
Somehow the i2c comm is hanging and thus blocking the app.

[ioannisg]

@mbolivar @anangl could you please take a look here?

[pabigot]

While this appears with sensors, I believe it is fundamentally an I2C problem. As noted recently on slack it's possible for the bus to get hung, causing transactions to be blocked until it's cleared---an operation that is not explicitly supported in Zephyr but can always be done by bitbanging.

[olsky]

It would be good to have a solution, as (although is not Zephyr's) when it hangs -- there is no way to react in the app... as the main is not yet reached.

[olsky]

I have one more "corner usecase": sensor is powered with a separate LDO.
Thus at boot time: the sensor is not available and thus cannot be inited.

At run-time, when the LDO is enabled and the power goes to sensors... what it the best way to "init" i2c sensors in Zephyr?

The "device_get_binding" is failing in this case, probably due to failure during boot time (call to: DEVICE_AND_API_INIT?).

Any workaround?

[pabigot]

I have one more "corner usecase": sensor is powered with a separate LDO.
Thus at boot time: the sensor is not available and thus cannot be inited.

At run-time, when the LDO is enabled and the power goes to sensors... what it the best way to "init" i2c sensors in Zephyr?

Look at nrf52_pca20020 which has this feature. In short, the board turns on the LDOs on boot, in necessary order, and leaves them on.

Otherwise you have to do it manually in the driver. For now, because that really has to change.

[olsky]

@pabigot thank you for suggestion! It worked (well, as expected) :)

[mbolivar]

@olsky do you think this issue can be closed?

[olsky]

@mbolivar is there any change in the sensor-API in the init phase?
I fixed that with the hint from @pabigot but in case there is some problems in i2c communication -- all just hangs. It would be good to place a timeout and let the board boot. Just my opinion :)

[mbolivar]

I think the workaround by @pabigot is really the best we can do for now until we have #22802 or something like it. Please reopen if you disagree.