nPM1300 one button example on custom board

[backstreet.devisor]

Hi.

I'm testing the "nPM1300 One Button" example, but I'm having some problems. 

When setting up the npm1300_ek.overlay file, I specify that pin P0.15 is the interrupt pin on my custom board (nRF52840) and GPIO3 is the interrupt initiator pin on the PMIC, but I keep getting a warning that pin 3 is already in use in the device tree.

npm1300_ek.overlay -->

custom_board_nrf52840.dts -->

When I start an application, the LED connected to pin P0.03 on my board lights up (although it shouldn't). The interrupt does not work and the board does not respond to button presses on the nPM1300 EK.

Can you please advise me why this is happening and how to fix it?

Also by default there are problems in the overlay file related to pin 2 on the EK. Is there any way to fix them or will they not affect correct operation?

Thanks.

[runsiv]

Hi 

I presume your custom board is based on the 52840dk? 

You can do the following in your overlay

/{
    leds {
        status = "disabled";
    };
}
You can remove the 'leds' node altogether by using /delete-node/. The LED nodes are being referenced by the aliases, so those need to be removed as well.



/ {
    aliases {
        /delete-property/ led0;
        /delete-property/ mcuboot-led0;
        /delete-property/ bootloader-led0;
    };

    /delete-node/ leds;

};

Regards

Runar

[backstreet.devisor]

Hi Runar. Thank you for your response.

My board is based on the nRF52840 (it's not a DK). If I understand you correctly, if I disable the leds node, I can no longer use LEDs in my application? I don't want to do that because the LEDs on my board play an important role. 

We need to find another solution to this problem.

Why does the pmic-int-pin = <3> property configure the pin to nRF52840 and not nPM1300?

[runsiv]

Thanks

When I look at the samples it looks like the npm1300 is defined in the overlay to the board. Not the npm1300. If you look at the zephyr dts in the build folder. Is the PMIC config included there? I will hopefully have an EK tomorrow and test myself

Regards

Runar

[backstreet.devisor]

Hi. 

Here is the part of the code associated with PMIC in the zephyr.dts file in the build folder. 

zephyr.dts -->

i2c1: i2c@40004000 {
			compatible = "nordic,nrf-twi";
			#address-cells = < 0x1 >;
			#size-cells = < 0x0 >;
			reg = < 0x40004000 0x1000 >;
			clock-frequency = < 0x186a0 >;
			interrupts = < 0x4 0x1 >;
			easydma-maxcnt-bits = < 0x10 >;
			status = "okay";
			pinctrl-0 = < &i2c1_default >;
			pinctrl-1 = < &i2c1_sleep >;
			pinctrl-names = "default", "sleep";
			npm1300_ek_pmic: pmic@6b {
				compatible = "nordic,npm1300";
				reg = < 0x6b >;
				host-int-gpios = < &gpio0 0xf 0x0 >;
				pmic-int-pin = < 0x3 >;
				npm1300_ek_gpio: gpio-controller {
					compatible = "nordic,npm1300-gpio";
					gpio-controller;
					#gpio-cells = < 0x2 >;
					ngpios = < 0x5 >;
					phandle = < 0xb >;
				};
				npm1300_ek_regulators: regulators {
					compatible = "nordic,npm1300-regulator";
					npm1300_ek_buck1: BUCK1 {
						regulator-min-microvolt = < 0x1b7740 >;
						regulator-max-microvolt = < 0x325aa0 >;
					};
					npm1300_ek_buck2: BUCK2 {
						regulator-min-microvolt = < 0xf4240 >;
						regulator-max-microvolt = < 0x325aa0 >;
						regulator-init-microvolt = < 0x325aa0 >;
						retention-microvolt = < 0x2625a0 >;
						enable-gpios = < &npm1300_ek_gpio 0x1 0x1 >;
						retention-gpios = < &npm1300_ek_gpio 0x2 0x0 >;
						pwm-gpios = < &npm1300_ek_gpio 0x2 0x1 >;
					};
					npm1300_ek_ldo1: LDO1 {
						regulator-min-microvolt = < 0xf4240 >;
						regulator-max-microvolt = < 0x325aa0 >;
						regulator-initial-mode = < 0x3 >;
						enable-gpios = < &npm1300_ek_gpio 0x2 0x1 >;
					};
					npm1300_ek_ldo2: LDO2 {
						regulator-min-microvolt = < 0xf4240 >;
						regulator-max-microvolt = < 0x325aa0 >;
						regulator-initial-mode = < 0x3 >;
						enable-gpios = < &npm1300_ek_gpio 0x2 0x1 >;
					};
				};
				npm1300_ek_charger: charger {
					compatible = "nordic,npm1300-charger";
					term-microvolt = < 0x401640 >;
					current-microamp = < 0x1d4c0 >;
					dischg-limit-microamp = < 0x927c0 >;
					vbus-limit-microamp = < 0x7a120 >;
					thermistor-ohms = < 0x2710 >;
					thermistor-beta = < 0xd34 >;
					charging-enable;
				};
				npm1300_ek_buttons: buttons {
					compatible = "gpio-keys";
					pmic_button0: pmic_button_0 {
						gpios = < &npm1300_ek_gpio 0x0 0x0 >;
						label = "Pmic button switch 0";
						zephyr,code = < 0xb >;
					};
				};
				npm1300_ek_leds: leds {
					compatible = "nordic,npm1300-led";
					nordic,led0-mode = "error";
					nordic,led1-mode = "charging";
					nordic,led2-mode = "host";
				};
			};
		};

Interruptions still don't work. Here is a screenshot from the logic analyzer (GPIO3 and SHPHLD button behavior). It might be of some help to you.

Thanks.

[Andy Sinclair]

Hi, from your logic analyser trace the rising edge on GPIO3 shows that the interrupt from the PMIC is being generated as expected by the falling edge on SHIPHOLD (NPM1300_EVENT_SHIPHOLD_PRESS).

The interrupt will only be cleared once it is detected by the host and the event registers are cleared by I2C.

Do you see the event detected on the console?

If not, can you check the state of P0.15 when the interrupt is active?
You should be able to so this by reading the pin state with code or a shell command.

[backstreet.devisor]

Hi, Andy. Thanks for answering.

I will check the status of P0.15 and give an answer shortly.

Do you happen to know why the pmic-int-pin property affects not only the pmic pin, but also the nRF52 pin?  The zephyr website says this property only applies to pmic.

Thanks.

[runsiv]

I do wonder if it is a intellisense error, I can replicate the same warning on a DK by switching the pin number

Regards

Runar

[Andy Sinclair]

I think you are correct.
It can't possibly affect anything else as that parameter is only used in a single place in the Zephyr codebase.

[backstreet.devisor]

Hi Runar.

runsiv said:

I do wonder if it is a intellisense error, I can replicate the same warning on a DK by switching the pin number

Could you please ask the developers what this bug is related to and if there is any way to fix it (or if it will be fixed in the future)?

I solved the interrupt problem, everything works fine now. The only thing left is to solve the problem with the pmic-int-pin property.

Thanks.

[runsiv]

I will report the issue internally

Good to hear the rest is working, 

Regards

Runar

[backstreet.devisor]

Thank you, Runar.

I will wait for news from you on solving this problem. 

Because if don't solve this problem, you can't use GPIO0 and GPIO1 on EK as interrupt pin, because they (P0.00 and P0.01) are allocated for quartz. And when using GPIO2, 3, 4 it is necessary to make sure that they are not used on nRF52.

[runsiv]

So I heard back from the developers. They will make a expectation for the specific property to avoid the warning. You can also safely ignore this warning as it has nothing to do with the pin.

Runar