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?

[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

[backstreet.devisor]

I got it. Thank you very much for your help.