Delayed Devicetree initialization for connected Sensors

3704.hello_world.zip

Hello,

I have connected a LSM6DSO sensor to my nRF52805 which is powered via GPIO. At startup zephyr RTOS wants to init the sensor and failed. After a reboot it detects the sensor and it works fine.

[00:00:00.000,213] *** Booting Zephyr OS build v3.0.99-ncs1-1  ***
<inf> LSM6DSO: Initialize device LSM6DSO
[00:00:00.002,960] <inf> LSM6DSO: chip id 0x0
[00:00:00.030,303] <inf> BATTERY: Setup AIN9 got 0
[00:00:00.030,303] <inf> BATTERY: Battery setup: 0 1
Hier wird 5 sec gewartet
waiting 2 seconds for pins to get up gpio initialisiert 



===============================================================
Could not find IMU sensor, aborting test.
IMU sensor Ed is not ready, aborting test.
[00:00:14.051,666] <err> os: ***** MPU FAULT *****
[00:00:14.051,696] <err> os:   Instruction Access Violation
[00:00:14.051,727] <err> os: r0/a1:  0x00000000  r1/a2:  0x00000003  r2/a3:  0x00000000
[00:00:14.051,727] <err> os: r3/a4:  0x200036c0 r12/ip:  0x20003614 r14/lr:  0x0000bba9
[00:00:14.051,757] <err> os:  xpsr:  0x21000000
[00:00:14.051,757] <err> os: Faulting instruction address (r15/pc): 0x45f7f4b4
[00:00:14.051,788] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:14.051,788] <err> os: Current thread: 0x200019f8 (main)
�[00:00:00.000,213] *** Booting Zephyr OS build v3.0.99-ncs1-1  ***
<inf> LSM6DSO: Initialize device LSM6DSO
[00:00:00.002,868] <inf> LSM6DSO: chip id 0x6c
[00:00:00.112,884] <inf> BATTERY: Setup AIN9 got 0
[00:00:00.112,884] <inf> BATTERY: Battery setup: 0 1
Hier wird 5 sec gewartet
waiting 2 seconds for pins to get up gpio initialisiert 



===============================================================
Bluetooth initialized
Beacon started, advertising as EF:F0:9B:1E:C2:0B (random)
[0:00:11.177]: 2957 mV; 8280 pptt
[0:00:11.221]:-21742.4 hPa
[0:00:11.223]:20 Cel
[0:00:11.225]:-0.008603 rpm
gyro x:-0.033750 dps y:-0.063835 dps z:0.045967 dps
[0:00:11.258]:0 minutes
----------------------------------

My question is: can I somehow control the device tree via an API in order to activate devices after startup process manually?

Top Replies

HSPalm 10 months ago in reply to JonasGel +1

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?

Parents

0 Øivind over 2 years ago

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?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Reply

0 Øivind over 2 years ago

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?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Children

0 JonasGel over 2 years ago in reply to Øivind

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.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Øivind over 2 years ago in reply to JonasGel

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
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

0 JonasGel over 2 years ago in reply to Øivind

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 :)

0 JonasGel over 2 years ago in reply to Øivind

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.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Øivind over 2 years ago in reply to JonasGel

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?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Reject Answer

Cancel