npm1300 zephyr driver documentation

[Yaxit]

Hi,

I'm developing now on a custom board with the npm1300. I see that there are two examples in NCS based on zephyr's drivers. Moreover, the nPM powerUP desktop application only exports an overlay file for use in the device tree with the zephyr driver.

However, I could not find detailed documentation of the Zephyr API's implementation of the driver, which callbacks are implemented and which ones are not etc.

For example, I can turn the LEDs on and off with the led driver, but `led_blink` doesn't do anything. I'm basically looking for documentation describing this stuff, since trial and error takes way too long for a chip with so many functionalities.

On a similar note, are these functions even thread-safe? I'm happy to use these drivers but only if I can trust them :D

Thank you!

[Kazi Afroza Sultana]

Hello,

''On a similar note, are these functions even thread-safe? I'm happy to use these drivers but only if I can trust them :D''

The drivers use the underlying I2C driver, which does have a lock (i.e. thread safe). I think a typical application might for example call the voltage regulator API from one part of the code, and perhaps the battery charger API from a different part. And that should be fine. However, there might be cases of read-modify-write patterns done by the driver which could have corner cases. For example, from reviewing the buck_set_voltage function, it seems like it might be possible to call regulator_set_voltage from separate priorities at the same time and get different results based on the order of i2c read/writes.

'' Moreover, the nPM powerUP desktop application only exports an overlay file for use in the device tree with the zephyr driver.''

Is it C code examples that is lacking here? 

It would be great with feedback of missing features in NCS or PowerUP.

''However, I could not find detailed documentation of the Zephyr API's implementation of the driver, which callbacks are implemented and which ones are not etc''

We don't have this granularity of documentation. I'm not sure many of the zephyr driver implementations has it either.

There are some open sources about the npm1300 driver code locations where the various APIs are being implemented are listed here

• LED driver API: https://github.com/nrfconnect/sdk-zephyr/blob/main/drivers/led/led_npm1300.c#L65
• GPIO driver API: https://github.com/nrfconnect/sdk-zephyr/blob/main/drivers/gpio/gpio_npm1300.c#L195
• Watchdog driver API: https://github.com/nrfconnect/sdk-zephyr/blob/main/drivers/watchdog/wdt_npm1300.c#L127
• (voltage) Regulator API: https://github.com/nrfconnect/sdk-zephyr/blob/main/drivers/regulator/regulator_npm1300.c#L637
• The charger is a bit tricky at the moment. The driver was written before there was a charger API, and as such it is currently implemented as a sensor device: https://github.com/nrfconnect/sdk-zephyr/blob/main/drivers/sensor/nordic/npm1300_charger/npm1300_charger.c#L610

[cellular_iot]

Just to take up this old discussion: I understand Nordic that reference designs should use as many nordic chips as possible. A demo device fully working out of the box with not much work required on customers side is worth its money in gold.
For an example my company is very successfull in LoraWAN based IoT products. Now we want to repeat this sccess with cellular-based IoT. Nordics nRF and Thingy91 seemed to be the perfect starting point as demo device, demo apps (MQTT and lwm2m_client) seemingly provide EVERYTHING we need in ecosystem, infrastructure, fuctionality and (low power) optimisatuon. That seemed to be a way better state when we devs are used to see at other vendors and we bought a handfull of devices and started developing. But it turned out that its still not enough and nRF9160 is not recommended for new products. So we bit the bullet and bought another handfull of Thingy91X - "X stands for eXtended, better, newer, greater" - as we all know. But what a bad surprise - Thingy91X is not yet suppurted as a Low Power Cellular IoT Sensor Device - its literally in the same state as the nRF9151DK. Nordic for example switched the PMIC from the well Zephyr-supported 3rd party ADP to the bad supported nPM1300. So a lot of customers and their devs hack their own incompatible nPM1300 support in order to get Thingy91X clones up and running. Now we have to decide if we go with a Thingy91 or a Thingy91X derived hardwaree design. Or we go with a hybrid - using all Thingy91 well-supprted 3rd party periperals and only go with the newer SiP. Or we just fall back to a standard modem solution. Greetings to marketing and finance that the decisition not giving the Nordic devs the time to bring nPM1300 and Thingy91X to the same level as Thingy91 will kill a lot of chips sales opportunities and drive customers to the competition.