regulator-powered sensor fails to acknowledge over i2c after replacing battery

[Lasto]

I'm using a custom board that has nRF52810 and lis2dh12 sensor. The sensor's Vdd is powered from a GPIO (configured a regulator-fixed to supply power from the GPIO during boot time).  GPIO's for I2C communications are configured with internal pull-ups. The code is same as lis2dh sample code.

For a while, the I2C communications to the sensor was working fine (RTT logged good sensor data), until the battery level went below 1.5V.

Now, the sensor is not acknowledging during lis2dh driver initialization in kernel's init.c (as if no supply is provided to the sensor). The issue persists after replacing the battery (with another battery and external power supply.

Could this be a simple timing issue during initialization?

[00:00:03.345,031] <inf> regulator_fixed: imu-pwr-ctrl onoff: 0
[00:00:09.659,393] <err> i2c_nrfx_twim: Error on I2C line occurred for message 0
[00:00:09.659,515] <err> lis2dhx: Failed to read chip id.

BTW, I inadvertently had added DC/DC configuration enabled (although the board has no external inductor to support DC/DC).

[Lasto]

A hard fault was reported after powering up the board this morning.

[00:00:00.004,211] <inf> regulator_fixed: lis2dh-pwr-reg onoff: 0
[00:00:00.004,241] <err> os: ***** HARD FAULT *****
[00:00:00.004,241] <err> os:   Debug event
[00:00:00.004,272] <err> os: r0/a1:  0x00000000  r1/a2:  0x00000001  r2/a3:  0x00000001
[00:00:00.004,272] <err> os: r3/a4:  0x0000cdc0 r12/ip:  0x00000002 r14/lr:  0x00005917
[00:00:00.004,302] <err> os:  xpsr:  0x61000000
[00:00:00.004,302] <err> os: Faulting instruction address (r15/pc): 0x0000549c
[00:00:00.004,364] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:00.004,394] <err> os: Current thread: 0x200007a0 (main)
[00:00:00.417,327] <err> fatal_error: Resetting system

Afterwards, the log shows the original error message:

[00:00:00.004,211] <inf> regulator_fixed: lis2dh-pwr-reg onoff: 0
[00:00:00.004,394] <err> i2c_nrfx_twim: Error 0x0BAE0001 occurred for message 0
[00:00:00.004,425] <err> lis2dh: Failed to read chip id.
[00:00:00.004,486] <inf> logging_main: Checking for sensor
[00:00:00.004,516] <inf> logging_main: Device lis2dh@19 is not ready

As reported above, each <i2c_dump_msgs> entry in the drivers initialization has <z_arm_reset> and <z_arm_usage_fault>.

I'm running a script that loops over "nrfjprog --recover" (not sure what to expect).

[Lasto]

I just checked the board circuit and verified the board matches the reference design of nRF52810, including the 10uH and 15 nH required for the DC/DC proper operation. (reference design link https://infocenter.nordicsemi.com/topic/ps_nrf52810/chapters/ref_circuitry/doc/image/nrf52810_qfaa_dcdc_schematic.svg)

So, I assume that this eliminates the possibility that the DC/DC converter as a culprit for the hard reset.

[Simonr]

If the DCDC components are in place, then this should not be the issue indeed, and the recovery command seems to be done correctly with "Recovering device. This operation might take 30s.
Erasing user code and UICR flash areas."

Regarding your setup, have you measured the voltage on the I2C sensor you have connected to see that it gets the necessary voltage it needs to run? Also, what operating voltages does this I2C sensor support exactly? It's also important to make sure that it doesn't go into some undefined state if the battery at some point goes below the required voltage. This should not be an issue with the nRF52, as the brown-out reset. From what I see in the logs you have provided it seems like the sensor isn't powered, so I would strongly recommend measuring with a multimeter or similar that it is indeed being provided the necessary power. If not, make sure that the GPIO providing it with power is enabled before the i2c_init() function is called.

Best regards,

Simon

[Lasto]

Thank you for your response.

The sensor Vdd (and IO) supply range is 1.71 V to 3.6 V.

I tested the regulator by switching the GPIO0.n to power up an LED and is working fine. I need to figure out how directly measure the voltage at the sensor since it is a tiny sensor on a 3rd-party board.

I agree that the " the sensor isn't powered" by the time the  sensor driver is attempting to verify sensor communications. The sensor is supposed to be powered by the regulator (which actually powers the LED in a separate test). The debug log shows that regulator's driver is invoked before the sensor driver.

10. dev.name: "lis2dh-pwr-reg" (api: <api_onoff>) -- regulator driver
11. dev.name: "lis2dh@19" (api: <lis2dh_driver_api>) sensor driver (error: seems sensor is not powered yet)

Could you please help me better understand the kernel initialization messages "z_arm_usage_fault" and 'z_arm_reset" associated with "dev: 0x0 <i2c_dump_msgs>" (please see above debug log)?

These messages occur very early in the driver initialization.

dev: 0x0 <i2c_dump_msgs>" has the following associated attributes:
    config: 0x42e1 <z_arm_reset>
    api: 0xa3e1 <z_arm_nmi>
    state: 04299 <z_arm_usage_fault>
    data: 04299 <z_arm_usage_fault>

[Lasto]

I just confirmed (using a voltmeter) that the required supply voltage, Vdd (and Vdd_IO), to the sensor switches from 0V to 3.3V once the regulator driver is executed in init.c() of the kernel initialization. It continues to be 3.3V when the following error is received from the sensor's driver while attempting to read back (ID Register) from the sensor:

[00:00:13.696,411] <inf> regulator_fixed: lis2dh-pwr-reg onoff: 0
[00:00:42.617,553] <err> i2c_nrfx_twim: Error on I2C line occurred for message 0
[00:00:42.617,614] <err> lis2dh: Failed to read chip id.
[00:00:44.646,881] <inf> logging_main: Checking for sensor
[00:00:44.646,911] <inf> logging_main: Device lis2dh@19 is not ready

There are no external pull-up resistors on the I2C lines (SDA and SCL). I assume internal pull-up are enabled by default, but I also tested by explicitly enabling them - no difference.

I also tested by the regulator delays (startup and off-on parameters), makes no difference either. In fact, during debugging I leave the regulator on for a while before attempting to run the sensor driver.

I'm not sure that I can get traces of the i2c communication lines, as done in another apparently related issue reported recently TWIM (I2C) on NCS is not working properly