Delayed Devicetree initialization for connected Sensors

RE: Delayed Devicetree initialization for connected Sensors

HSPalm — Fri, 09 Aug 2024 08:33:51 GMT

Hi Jonas,

I see you marked Øyvinds answer below to resolve your issue (?). Can you explain which part of it was the correcting factor for your problem?

RE: Delayed Devicetree initialization for connected Sensors

Øivind — Fri, 30 Sep 2022 10:18:43 GMT

Hi again,

Try adding CONFIG_REGULATOR=y

And what does your overlay file look like now? You should move the i2c1 and i2c2 nodes out of the / { } brackets, and reference them with &i2c1 and &i2c2, like you do with &i2c0.

If it still does not work, can you attach the current version of the project?

RE: Delayed Devicetree initialization for connected Sensors

JonasGel — Wed, 28 Sep 2022 15:31:54 GMT

Hi Øivind,

After debugging the firmware the past days I haven't found a way to influence the initialization of the devicetree components. Further I found two similar (but older) cases, where devices are not powered while booting:
https://devzone.nordicsemi.com/f/nordic-q-a/79431/initialise-periphery/330615
https://devzone.nordicsemi.com/f/nordic-q-a/81579/initialize-device-to-device_pm_off_state

is there now a way to influence these initializations, or to control them later from the main function?
Maybe you have any working example with a sensor connected with i2c and powered by a gpio?

I further experimented with pm_device_init_off(dev); but I am not able to start the devices properly again.

RE: Delayed Devicetree initialization for connected Sensors

JonasGel — Mon, 26 Sep 2022 08:08:01 GMT

Hi,

Yes It works all fine in two situations with correct measurements:

1. Connecting the Sensors to the Vdd input Voltage (2,98V - equivalent to GPIO Voltage)
2. Connecting the Sensors to Vdd at boot-time and switch to the dedicated GPIO (2 & 23) after the initialization process.

If the sensors are plugged into the GPIOs at boot-time, the nRF resets after failing at sensor initialization, then gets the correct chip ID after restart and measures correct IMU-Values and incorrect Pressure Values.

(So I get good measurements with both (GPIO and Vdd) Voltage, but it has to be started with Vdd-Voltage). So I think the initialization process has to have more delay to build up GPIO-voltage or should be triggered manual in the main-function, but i don't know how exactly.

I have tried your advice to change the initialization-level for sensor. This delayed the initialization of the Sensor about 25ms but doesn't change the behavior of the initialization process.

With POST_KERNEL-level, the console Output looks like this:

[00:00:00.000,183] *** Booting Zephyr OS build v3.0.99-ncs1-1  ***
waiting 2 seconds for pins to get up gpio initialisiert 
<inf> LSM6DSO: Initialize device LSM6DSO
[00:00:00.002,929] <inf> LSM6DSO: chip id 0x0



===============================================================
Could not find IMU sensor, aborting test.
IMU sensor uI is not ready, aborting test.
[00:00:09.049,285] <err> os: ***** BUS FAULT *****
[00:00:09.049,316] <err> os:   Instruction bus error
[00:00:09.049,346] <err> os: r0/a1:  0x00000000  r1/a2:  0x00000003  r2/a3:  0x00000000
[00:00:09.049,346] <err> os: r3/a4:  0x20002ac0 r12/ip:  0x20002a14 r14/lr:  0x0000b969
[00:00:09.049,346] <err> os:  xpsr:  0x21000000
[00:00:09.049,377] <err> os: Faulting instruction address (r15/pc): 0x0af7f6b4
[00:00:09.049,407] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:09.049,407] <err> os: Current thread: 0x20001838 (main)
�[00:00:00.000,213] *** Booting Zephyr OS build v3.0.99-ncs1-1  ***
waiting 2 seconds for pins to get up gpio initialisiert 
<inf> LSM6DSO: Initialize device LSM6DSO
[00:00:00.002,838] <inf> LSM6DSO: chip id 0x6c



===============================================================
[0:00:06.198]:-21742.4 hPa
[0:00:06.201]:20 Cel
[0:00:06.203]:-0.006949 rpm
gyro x:-0.037568 dps y:-0.058643 dps z:0.054519 dps
----------------------------------

With APPLICATION-level for LSM6DSO, the output is:

*** Booting Zephyr OS build v3.0.99-ncs1-1  ***
waiting 2 seconds for pins to get up gpio initialisiert 
[00:00:00.027,526] <inf> LSM6DSO: Initialize device LSM6DSO
[00:00:00.030,303] 


==============================================================
[0m<inf> LSM6DSO: chip id 0x0
Could not find IMU sensor, aborting test.
IMU sensor uI is not ready, aborting test.
[00:00:09.049,316] <err> os: ***** BUS FAULT *****
[00:00:09.049,377] <err> os:   Instruction bus error
[00:00:09.049,377] <err> os: r0/a1:  0x00000000  r1/a2:  0x00000003  r2/a3:  0x00000000
[00:00:09.049,407] <err> os: r3/a4:  0x20002ac0 r12/ip:  0x20002a14 r14/lr:  0x0000b969
[00:00:09.049,407] <err> os:  xpsr:  0x21000000
[00:00:09.049,438] <err> os: Faulting instruction address (r15/pc): 0x0af7f6b4
[00:00:09.049,438] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:09.049,468] <err> os: Current thread: 0x20001838 (main)
�*** Booting Zephyr OS build v3.0.99-ncs1-1  ***system
waiting 2 seconds for pins to get up gpio initialisiert 
[00:00:00.027,557] <inf> LSM6DSO: Initialize device LSM6DSO
[00:00:00.030,212] <inf> LSM6DSO: chip id 0x6c

further I tried to edit the Levels in i2c_gpio.c, but this helps neither.

many thanks for the help :)

RE: Delayed Devicetree initialization for connected Sensors

Øivind — Fri, 23 Sep 2022 10:26:32 GMT

Ok, I'll look into this.

To be clear, with Vdd it works the first time, and the measurements are correct?
But when powered by a GPIO, it fails to initialize, then after a reset it is able to initialize, but then the measurements are wrong?
So you are only able to get good measurements with Vdd?

Not sure if this will work, but can you try changing this line from POST_KERNEL to APPLICATION? If it doesn't work just change it back.

https://github.com/nrfconnect/sdk-zephyr/blob/v3.0.99-ncs1-1/drivers/sensor/lsm6dso/lsm6dso.c#L870

RE: Delayed Devicetree initialization for connected Sensors

JonasGel — Thu, 22 Sep 2022 10:50:11 GMT

Hello,

I just created a new hello_world Project and added it to the Attachment. In this Project I reduced the code to the Sensor initialization and readings.

The Project is done with nRF Connect SDK 2.0.2
There are 2 sensors attached on separate Bitbang-I2C busses

The Sensors are powered via GPIO outputs from the nRF52805. The power consumption of both sensors is beneath the maximum current ratings.

If I start the board with Sensors powered by Vdd all works fine and the detected measurements are fine. I can unplug from Vdd and plug them in the GPIO and they work well with the voltage provided by the GPIO outputs.

If I start the Board with Sensors plugged in to the GPIO, the error-message from above is shown, the nRF resets and recognize the IMU sensor only at the second start. The displayed values measured from the Sensors are incorrect.

In my understanding the Sensors were initialized before the GPIO voltage is present. I have tested to increase the initialization priority for sensor devices and decrease for the GPIO interface, but this doesn't work for me.

I would like to control the initialization process from the main-function or add a configuration that provides the sensors with power first and only the start the sensor initialization process.

I always had this issue.

RE: Delayed Devicetree initialization for connected Sensors

Øivind — Thu, 22 Sep 2022 09:57:16 GMT

Hi,

It seems like you are running an application you wrote yourself. Could you post the code that runs between start-up and the error?

Have you always had this issue since using the sensor? Have you tried adding the sensor to a sample application, like hello_world?