nPM1300 driver – hidden i2c communication when testing fuel gauge example

[David Lohuis]

Hello everyone,

I am exploring the nPM1300 EK so that I can use it in future projects. My overall goal is to be able to use it with an nRF52 as well as an stm32 host controller. For that I followed the path to the corresponding zephyr drivers from your website (github.com/.../npmx-zephyr). I have downloaded and integrated the drivers successfully into my zephyr dev tools. As a first test I compiled the LED example on an nrf52840dk and it worked completely fine. Adjusting the code for an stm32 MCU was also not a problem and I got it to work as well.

I first ran into problems after I tried to run the Fuel Gauge example on my stm32 MCU. It led to the following runtime error.

*** Booting Zephyr OS build zephyr-v3.3.0 ***
[00:00:00.000,000] <inf> main: PMIC device OK.
[00:00:00.001,000] <err> fuel_gauge: Reading ADC measurements failed.
[00:00:00.001,000] <err> main: Fuel gauge initialization failed.

In order to resolve this issue, I investigated the i2c communication and compared it with a working system using my nrf52840dk. As a result, I noticed, that some sensor initialization happens outside the application code. This initialization is somehow only working on the nrf52840dk and not the stm32. This means, that even if I uncomment the whole code in main.c there is still some communication going on between the nPM1300 and the host controller, which am not able to locate in the code.

I could use any insight about how to find the function responsible for this communication and how I can debug it. It is my current understanding that this happens inside the driver, which must be adjusted in order to work properly on an stm32. Any links, where I can find more detailed driver documentation is also appreciated. 

Thanks and kind regards 

David 

[Andy Sinclair]

Hi David.

The driver initialization code configures the device using I2C writes before the application starts (e.g.: https://github.com/zephyrproject-rtos/zephyr/blob/0186a9641976fac1589f6a431f7f4a98c5dca6ae/drivers/regulator/regulator_npm1300.c#L581)

This code should not need modification to work with a different MCU though, as it contains platform agnostic I2C transactions and is not Nordic specific.

Have you checked the I2C traces to check they look OK?
I2C problems (missing connection / no pullup etc.) may manifest like this.

Andy

[David Lohuis]

Hey Andy,

Thanks for your quick response. I understand that the driver initialization is responsible and is not meant to be modified. I can confirm that the two i2c lines are properly connected and two external pull up resistors are added. The communication is logged via the “CONFIG_I2C_DUMP_MESSAGES” configuration. Using my oscilloscope, I can see how the log data is present on the i2c lines. The problem is, that my stm32 is not executing the driver initialization. It only sends bytes from driver functions in the application code.

I can see that the first bytes on my nrf52840 are 0x00 0x05 and after multiple bytes it sends 0x17 0x18. The stm32 on the other hand starts with the byte sequence 0x17 0x18. From disabling the application code I can see how this missing byte sequence is exactly the initialization send by the driver. So somehow the driver initialization is not executed properly by the stm32 and I don’t know why and how to debug it.

Kind regards

David

[Andy Sinclair]

Hi David.

Thanks for your comprehensive reply.
That sounds really strange.  The only thing that immediately springs to mind is an issue with initialisation order.
Could you post the first full I2C message that is only on the nrf52840 please?

Can you clarify if you are planning to use a Zephyr development environment or bare metal for your final application?

If you are using Zephyr, I recommend you take a look at the native Zephyr and NCS samples here:

zephyr/samples/shields/npm1300_ek/src/main.c at 06caa9cde648842278118afd91a0adfe51ab194c · zephyrproject-rtos/zephyr (github.com)

sdk-nrf/samples/pmic/native/npm1300_fuel_gauge at main · nrfconnect/sdk-nrf (github.com)

[David Lohuis]

Hi Andy, 

That is indeed really strange and I am working on it for a couple of weeks now. I am currently working with zephyr and I would like to do so in my final application. It is my current understanding, that I can utilize a lot of drivers which fulfill my requirements so that I do not need to go for bare metal. 

Here are the logs of the i2c communication which happens during the initialization phase and are not send by the stm32. I got them using my nRF52840 as you requested. 

[J[00:00:00.252,563] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@40004000, addr=6b
[J[00:00:00.252,655] <dbg> i2c: i2c_dump_msgs_rw:    W  len=02: 
[J[00:00:00.252,685] <dbg> i2c: i2c_dump_msgs_rw: contents:
                              00 05                                            |..               

[J[00:00:00.252,746] <dbg> i2c: i2c_dump_msgs_rw:    W P len=01: ff
[J[00:00:00.253,265] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@40004000, addr=6b
[J[00:00:00.253,295] <dbg> i2c: i2c_dump_msgs_rw:    W  len=02: 
[J[00:00:00.253,326] <dbg> i2c: i2c_dump_msgs_rw: contents:
                              00 03                                            |..               

[J[00:00:00.253,387] <dbg> i2c: i2c_dump_msgs_rw:    W P len=01: ff
[J[00:00:00.253,906] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@40004000, addr=6b
[J[00:00:00.253,967] <dbg> i2c: i2c_dump_msgs_rw:    W  len=02: 
[J[00:00:00.253,997] <dbg> i2c: i2c_dump_msgs_rw: contents:
                              00 09                                            |..               

[J[00:00:00.254,028] <dbg> i2c: i2c_dump_msgs_rw:    W P len=01: ff
[J[00:00:00.254,577] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@40004000, addr=6b
[J[00:00:00.254,638] <dbg> i2c: i2c_dump_msgs_rw:    W  len=02: 
[J[00:00:00.254,638] <dbg> i2c: i2c_dump_msgs_rw: contents:
                              00 07                                            |..               

[J[00:00:00.254,699] <dbg> i2c: i2c_dump_msgs_rw:    W P len=01: ff
[J[00:00:00.255,218] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@40004000, addr=6b
[J[00:00:00.255,249] <dbg> i2c: i2c_dump_msgs_rw:    W  len=02: 
[J[00:00:00.255,279] <dbg> i2c: i2c_dump_msgs_rw: contents:
                              00 0d                                            |..               

[J[00:00:00.255,340] <dbg> i2c: i2c_dump_msgs_rw:    W P len=01: ff
[J[00:00:00.255,859] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@40004000, addr=6b
[J[00:00:00.255,889] <dbg> i2c: i2c_dump_msgs_rw:    W  len=02: 
[J[00:00:00.255,920] <dbg> i2c: i2c_dump_msgs_rw: contents:
                              00 0b                                            |..               

[J[00:00:00.255,950] <dbg> i2c: i2c_dump_msgs_rw:    W P len=01: ff
[J[00:00:00.256,500] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@40004000, addr=6b
[J[00:00:00.256,530] <dbg> i2c: i2c_dump_msgs_rw:    W  len=02: 
[J[00:00:00.256,561] <dbg> i2c: i2c_dump_msgs_rw: contents:
                              00 11                                            |..               

[J[00:00:00.256,591] <dbg> i2c: i2c_dump_msgs_rw:    W P len=01: ff
[J[00:00:00.257,110] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@40004000, addr=6b
[J[00:00:00.257,171] <dbg> i2c: i2c_dump_msgs_rw:    W  len=02: 
[J[00:00:00.257,202] <dbg> i2c: i2c_dump_msgs_rw: contents:
                              00 0f                                            |..               

[J[00:00:00.257,232] <dbg> i2c: i2c_dump_msgs_rw:    W P len=01: ff
[J[00:00:00.257,751] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@40004000, addr=6b
[J[00:00:00.257,812] <dbg> i2c: i2c_dump_msgs_rw:    W  len=02: 
[J[00:00:00.257,812] <dbg> i2c: i2c_dump_msgs_rw: contents:
                              00 15                                            |..               

[00:00:00.257,873] <dbg> i2c: i2c_dump_msgs_rw:    W P len=01: ff
[00:00:00.258,392] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@40004000, addr=6b
[00:00:00.258,422] <dbg> i2c: i2c_dump_msgs_rw:    W  len=02: 
[00:00:00.258,453] <dbg> i2c: i2c_dump_msgs_rw: contents:
                              00 13                                            |..               

[00:00:00.258,514] <dbg> i2c: i2c_dump_msgs_rw:    W P len=01: ff
[00:00:00.259,033] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@40004000, addr=6b
[00:00:00.259,063] <dbg> i2c: i2c_dump_msgs_rw:    W  len=02: 
[00:00:00.259,094] <dbg> i2c: i2c_dump_msgs_rw: contents:
                              00 19                                            |..               

[00:00:00.259,124] <dbg> i2c: i2c_dump_msgs_rw:    W P len=01: ff
[00:00:00.259,674] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@40004000, addr=6b
[00:00:00.259,704] <dbg> i2c: i2c_dump_msgs_rw:    W  len=02: 
[00:00:00.259,735] <dbg> i2c: i2c_dump_msgs_rw: contents:
                              00 17                                            |..               
 
[00:00:00.259,765] <dbg> i2c: i2c_dump_msgs_rw:    W P len=01: ff 
[00:00:00.260,284] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@40004000, addr=6b 
[00:00:00.260,345] <dbg> i2c: i2c_dump_msgs_rw:    W  len=02: 
[00:00:00.260,375] <dbg> i2c: i2c_dump_msgs_rw: contents:
                              00 1d                                            |..               

[00:00:00.260,406] <dbg> i2c: i2c_dump_msgs_rw:    W P len=01: ff 
[00:00:00.260,925] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@40004000, addr=6b
[00:00:00.260,986] <dbg> i2c: i2c_dump_msgs_rw:    W  len=02: 
[00:00:00.261,016] <dbg> i2c: i2c_dump_msgs_rw: contents:
                              00 1b                                            |..               

[00:00:00.261,047] <dbg> i2c: i2c_dump_msgs_rw:    W P len=01: ff
[00:00:00.261,566] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@40004000, addr=6b
[00:00:00.261,596] <dbg> i2c: i2c_dump_msgs_rw:    W  len=02: 
[00:00:00.261,627] <dbg> i2c: i2c_dump_msgs_rw: contents:
                              00 25                                            |.%               

[00:00:00.261,688] <dbg> i2c: i2c_dump_msgs_rw:    W P len=01: ff
[00:00:00.262,207] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@40004000, addr=6b
[00:00:00.262,268] <dbg> i2c: i2c_dump_msgs_rw:    W  len=02: 
[00:00:00.262,268] <dbg> i2c: i2c_dump_msgs_rw: contents:
                              00 23                                            |.#               
 
[00:00:00.262,329] <dbg> i2c: i2c_dump_msgs_rw:    W P len=01: ff
[00:00:00.262,847] <dbg> i2c: i2c_dump_msgs_rw: I2C msg: i2c@40004000, addr=6b
[00:00:00.262,908] <dbg> i2c: i2c_dump_msgs_rw:    W  len=02: 
[00:00:00.262,939] <dbg> i2c: i2c_dump_msgs_rw: contents:
                              06 00                                            |..               
 
[00:00:00.262,969] <dbg> i2c: i2c_dump_msgs_rw:    W P len=01: 05
 
*** Booting Zephyr OS build zephyr-v3.3.0 ***

Yes I am using zephyr at the moment and I am planing o use it for my final application as well. It provide drivers, which are helpful and fulfill my requirements so that I don't have to write everything by my self. 

The links you provided look promising and I will look into them. The second example I already tried on my nRF52, where it worked fine. The first example is more interesting, since I haven't found it yet. I will try to work with it to see if I can get some new information regarding this issue.