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

[Simonr]

Hi

If you have enabled the DCDC configuration without the necessary components that will put the nRF device in a hardware-wise reset look I'm afraid. To fix this, the surefire way is to mount the required inductors onto the board if possible, but you can also try running a script continuously trying nrfjprog --recover. This will require some luck to catch it between resets however.

Best regards,

Simon

[Lasto]

Thank you for your help. How'd I know that the device was recovered? What tests should I run?

For example, I ran the recovery command once and it seems to be successful. I can try to run the script to loop over the command.
PS D:\nRF5\prjs\test21> nrfjprog --recover;
Recovering device. This operation might take 30s.
Erasing user code and UICR flash areas.

Would that "hardware-wise reset lock" cause the i2c driver to fail in init.c while attempting to establish communications to a device (that is being powered by the regulator (via GPIO) during boot time)?

I tested the regulator by flashing and successfully running a blinky controlled by GPIO & regulator. Working fine.

I found similar issues on DevZone for a similar device. I followed similar steps but they do not resolve the timing issue in the OP, but perhaps can be used to reproduce issue. I can attach .config and dts from the build directory of the board tree and the sample app for more info.
Powering Sensor-Device via GPIO and delay i2c communication - Devicetree implementation - Nordic Q&A - Nordic DevZone
Powering sensor through GPIO - Nordic Q&A - Nordic DevZone

[rajeev]

I have used GPIO to power all the sensors on my board without issues: mainly SHT4x and LIS2DH

Have a look at our device tree configuration for this board here:
https://github.com/Conexiotechnologies/conexio_stratus_devicetree/blob/v2.1.0/conexio_stratus/conexio_stratus_common.dts#L98

Hope it helps.

Rajeev

[Lasto]

Thanks Rajeev for your response.

I might be wrong but it seems, from your device tree, that the sensors are powered externally by the board not by nRF52. So, by the time the sensor drivers are invoked, during boot, the sensors are guaranteed to have power.

[Lasto]

Hope a driver initialization sequence from a debugging session will help.

The following is a summary of the driver initialization sequence and kernel levels obtained by placing a breakpoints in the kernel's init.c (static void z_sys_init_run_level(enum init_level level))

Drivers initialization
======================
 
	---- level: INIT_LEVEL_PRE_KERNEL_1 ----
	01. dev.name: <sys_work_q_stack> config: z_arm_reset> dev: 0x0 <i2c_dump_msgs> 
	02. dev.name: "clock@40000000"
	03. dev.name: <sys_work_q_stack> config: z_arm_reset> dev: 0x0 <i2c_dump_msgs>
	04. dev.name: <gpio_nrfx_p0_cfg>
	05. dev.name: <uart@40002000>
	
	---- level: INIT_LEVEL_PRE_KERNEL_2 ----
	06. dev.name: <sys_work_q_stack> config: z_arm_reset> dev: 0x0 <i2c_dump_msgs>
	
	---- level: INIT_LEVEL_POST_KERNEL ----
	07. dev.name: <sys_work_q_stack> config: z_arm_reset> dev: 0x0 <i2c_dump_msgs>
	08. dev.name: <sys_work_q_stack> config: z_arm_reset> dev: 0x0 <i2c_dump_msgs>
	09. dev.name: "i2c@40003000" (api: <i2c_nrfx_twim_driver_api>) i2c 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)
	12. dev.name: "temp@4000c000"

Each entry of "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>
	levels:[6]
	entry: 0xbf24 <__init_nordicsemi_nrf52_init>
	shows up at all kernel levels (See above)