I CANNOT USE nPM 2100 EK WITH CR2023

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Simonr — Thu, 11 Jun 2026 11:19:02 GMT

Szabolcs asked me to take a look at your firmware and other questions here.

1. I don't see any obvious issues/red flags with your PWM code or configuration. For more of a reference you can also check out the DevAcademy where we have a lesson on how to use the PWM in the nRF Connect SDK, as well as on how optimize current consumption on your nRF54L series designs.

3. To best optimize current consumption, logging and serial should be turned off unless you absolutely need it for your application at least, with CONFIG_SERIAL=n and CONFIG_LOG=n for example. You can also check out the Zephyr power management subsystem that integrates power management support in the RTOS.

Best regards,

Simon

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Szabolcs — Wed, 10 Jun 2026 12:15:00 GMT

Hi Luiz,

I'm happy to hear that. Looks like your project is coming along nicely.

Regarding question #2: There might be some tricks with LC-tanks or something that could increase the amplitude of the signal. I don't really have much experience with piezos so I'm afraid my knowledge ends here. You could ask about this buzzer driving circuit specifically on other forums, like electronics stackexchange, where you'll find people experienced in all kinds of things.

If you need fuel gauging, then the nPM1304 is a better choice, it has a built-in solution to do that. The Nordic-provided drivers would be the most accurate, these are tested by our department thoroughly.

Regarding your other questions, I'll ask my coworkers to confirm those. You code looks good to me, but I'm more specialized on hardware design than firmware development.

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Luiz Miranda — Sat, 06 Jun 2026 20:48:14 GMT

Hi Szabolcs,

I hope this email finds you well.

Following up on your last advice, I would like to share that we successfully managed to set up our test bench and validate the first firmware integration for the project using the nRF Connect SDK.

Here are the details of our current hardware implementation on the breadboard:

Software Environment: Developed using nRF Connect SDK v3.2.1 within VS Code, targeting the nrf54l15dk_nrf54l15_cpuapp build configuration.

Acoustic/Driver Circuit: Passive Piezo Buzzer (CPT-2746-L100), driven by a 2N3904 NPN BJT transistor, a 1 kΩ base resistor, and a 100 µF decoupling capacitor.
Power Supply: The breadboard is powered by the nPM2100 EK ( $V_{OUT}$ set to 3.0V), which is connected via USB.
Grounding: A common ground (GND) was carefully established between the nPM2100 EK and the nRF54L15 DK.
Control/MCU: The nRF54L15 DK is powered via USB, and we routed the hardware PWM signal through pin P1.11 directly to the breadboard transistor circuit.

On the software side, we developed an application to generate a continuous 4 kHz square wave with a 50% duty cycle to match the buzzer's resonant frequency. I am attaching our main.c, app.overlay, and prj.conf files for your review.

Test Results:

The firmware compiled flawlessly, and the driver initialized correctly. The buzzer successfully outputs a continuous and stable tone. However, the sound output volume remains very low.

We already ordered and are planning to transition to our target architecture (nPM1300-EK, an integrated H-Bridge DRV8837, and a 3.7V 250mAh Li-Po battery) in about 2 weeks to achieve the required 80 dB output via differential driving ( $V_{PP}$ ).

In the meantime, I would highly appreciate your expert opinion on the following questions:

Firmware Review: Looking at the attached files, do you see any issues with our current Zephyr RTOS PWM and Pinctrl configuration? Do you have any suggestions or best practices to optimize it for the nRF54L series?
Acoustic Volume: Do you think there is anything we could do to increase the buzzer volume using our current single-transistor 3.0V topology before our H-Bridge and nPM1300 arrive?
Low-Power Transition: In our main.c, we are using k_sleep(K_FOREVER) right after enabling the PWM, relying on the peripheral hardware to sustain the frequency. Is this the most power-efficient approach for the nRF54L15 Application Core during a buzzer alert, or should we look into specific low-power PM modes or Latency settings?
nPM1300 Preview: Since we will be using the nPM1300 soon, do you recommend using the native Zephyr shell/drivers for basic battery fuel gauging, or should we plan on implementing runtime I2C configuration using specific Nordic APIs for better precision?

Thank you so much for your continuous support and valuable insights into our development process.

Best regards,

Luiz

devzone.nordicsemi.com/.../6471.app.overlay devzone.nordicsemi.com/.../44273.main.c devzone.nordicsemi.com/.../8272.prj.conf

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Szabolcs — Thu, 28 May 2026 11:15:29 GMT

Hi Luiz,

I'm glad to hear that I could provide you with useful advice.

Yes, the nRF SDK and Zephyr has drivers for the nPM1300. You can configure the PMIC from the Device Tree files, and also use C functions in the library to change the configuration runtime. There are sample projects provided for the nPM1300-EK, you can see how it is done in them. You can find information for all of these on docs.nordicsemi.no. You can also use the Nordic AI (bottom right corner) to help you with generating code for your project.

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Luiz Miranda — Wed, 27 May 2026 19:06:01 GMT

Hi Szabolcs,

Thank you very much for your insightful feedback!

Your warning about the challenges of a discrete H-Bridge (shoot-through, dead-timing, and synchronization of 4 GPIOs) was incredibly valuable. Based on your recommendation, we have completely dropped the discrete topology. We decided to use a dedicated integrated low-voltage H-Bridge IC instead, specifically the DRV8837C, which handles all these protections and dead-time logic internally. This will definitely save us from a lot of development headaches and keep our PCB layout safe.

We also followed your advice regarding Option B (the Jauch LP502030JH 250mAh Li-Po). We will place it strategically on the back of the PCB to ensure a proper ground plane and keep the nRF54L15 antenna area completely clear ("keep-out zone") for optimal RF performance.

We are now ordering the nPM1300-EK to begin our official prototyping phase on the bench, using the Online Power Profiler to simulate and optimize our BLE connection intervals for the 15-30 days standby target.

As we prepare the firmware architecture to connect the nPM1300-EK and nRF54L15 DK, I have one quick question regarding the nPM1300:

Does the Zephyr RTOS already have production-ready driver samples for configuring the nPM1300 charging current (e.g., limiting it to 50mA via I2C) directly from the nRF54L15 code, or should we plan to implement those register configurations manually?

Thank you once again for guiding us toward a much more robust and professional architecture for the Project. I will keep you updated as soon as we have our first bench test results!

Best regards,

Luiz Miranda

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Szabolcs — Wed, 27 May 2026 13:49:22 GMT

Hi Luiz,

That is a very good idea, using a rechargeable Lithium battery is a wise decision.

I would recommend option B, as you have more capacity and a rectangular battery utilizes the available space more effectively than a round one. It can even be placed as to not overlap with the antenna, which is a good thing.

The antenna would have better performance if you would, say, double the PCB size, but adjusting just a few millimeters does not have much effect, so I would not change the board dimensions. A good routing and proper grounding is much more important for RF performance.

To answer your questions:

This is a very complex topic, and we don't really have a set of parameters that just works best for all. There is, however, a great tool that you can use to simulate the current consumption: https://devzone.nordicsemi.com/power/w/opp/2/online-power-profiler-for-bluetooth-le
A discrete H-Bridge could definitely work, but it introduces a lot of challenges by itself. You would need 4 GPIO pins working with close timing, aligned precisely to control the MOSFETS. You'll have to look out for shoot-through, ramp times, dead-timing between P and N channels, saturation voltages, etc. Overall, it is another complex design problem, and in my opinion, it is just not worth it. You can get an IC that does all that perfectly with a simple interface, and saves you a lot of headache.

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Luiz Miranda — Mon, 25 May 2026 03:10:34 GMT

Hi Szabolcs:

Thank you very much for your honest and highly valuable technical feedback.

Your calculations regarding the 13 mA current draw on the coin cell were spot on, and it made us completely rethink our power architecture to protect the project from voltage sag and brownout issues.

Based on your recommendations, we have a plan to upgrade our power management strategy for the FRA Project:

1 We are migrating from the nPM2100 to the nPM1300 family to take advantage of its integrated Lithium battery charger, power path management, and advanced fuel gauge.

2 We are switching to a rechargeable Lithium chemistry (3.7V) to ensure a much lower ESR, allowing the passive piezo to trigger continuously without affecting the nRF54L15 rails.

Since our mechanical enclosure constraint is tight (4.5 cm x 3.0 cm), we are currently evaluating two battery form factors and would highly appreciate your professional insight on them regarding their performance with the nPM1300:

Please note that while our current baseline is 4.5 cm x 3.0 cm, we have some flexibility to slightly increase the PCB dimensions if required to optimize the antenna ground plane or to better accommodate the power management section."

Option A: LIR2450 (Coin Cell): Compact circular footprint (24mm diameter), but requires a rigid PCB holder and offers around 120 mAh.

Option B: Small Pouch Li-Po (e.g., 502030): Rectangular footprint (20mm x 30mm x 5mm), which aligns nicely with our PCB edges, allows a "sandwich" mounting on the back of the board, and doubles the capacity to around 250 mAh.

Given that our target is to maintain a constant BLE connection to a Mobile APP with a target standby autonomy of 15 to 30 days, we have two quick questions:

1 BLE Parameters: To achieve our 15-30 days battery target while maintaining a continuous connection, what baseline values would you recommend for the Connection Interval and Peripheral Latency within the Zephyr RTOS? (A slight delay in mobile app command responsiveness is perfectly acceptable for this product).

2 Discrete H-Bridge: We plan to drive the passive piezo at 4.5 kHz using the nRF54L15 PWM. To achieve the 80 dB target at a regulated 3.3V, we are planning a discrete, low-cost H-Bridge circuit using two 2N7000 (N-Channel) and two BS250 (P-Channel) MOSFETs. Does this discrete topology look safe and appropriate to be driven directly by the nRF54 GPIOs?

Best regards,
Luiz Miranda

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Szabolcs — Fri, 22 May 2026 11:15:54 GMT

Hi Luiz,

We don't have much experience with using piezo buzzers, especially together with nPM applications. This is not a very common use case, so we rarely see projects like this. I will try to answer your questions as best as I can, but keep in mind, that these are just my professional opinions and could have some mistakes.

[quote user="Luiz Miranda"]What are the official recommendations for the driver circuit topology (e.g., migrating to an N-channel MOSFET like the 2N7002, an H-bridge configuration, or sticking with a standard BJT) to safely and efficiently achieve 80 dB at 3.0V or below?[/quote]

A single MOSFET is of course the simplest solution, but a full H-bridge can probably achieve more output power since it drives the buzzer "both ways". Maybe the buzzer of the evaluation kit you're using has some recommendations regarding the driver.

[quote user="Luiz Miranda"] What are the ideal values and types of bulk/decoupling capacitors (low-ESR ceramic vs. electrolytic) recommended to shield the nPM2100 power rail from the heavy current ripples caused by the 4 kHz piezo PWM switching?[/quote]

Since the buzzer is operating for seconds, the capacitors don't really make a difference. We recommend using the reference design for the nPM.

The best way to go forward with this is hooking up oscilloscope to the VBAT/VOUT of nPM2100 and also measuring battery current as well as the load current during piezo buzzing and seeing what actually is going on. If for example you see the voltage sagging with the 4kHz buzz frequency, then this could be helped with additional capacitors on the VINT. How much, depends on the load. We don't know that...

[quote user="Luiz Miranda"] Are there any specific application notes or reference designs from Nordic combining the nPM2100 and passive piezo transducers operating on high-impedance coin cells (CR2032)? [/quote]

No, unfortunately, we don't have anything like that.

[quote user="Luiz Miranda"]Is it possible to achieve a minimum of 80dB with the CR2032? If not, which battery would be best? CR2450, for example CR2450?[/quote]

The piezo element you mentioned draws around 13 mA (3.3V / 250Ohm), which is kind of the limit of a CR2032 battery. A bigger coin cell could work better, as they have lower ESR, which means lower voltage drop on loading. I recommend using AAA batteries, as they have very low ESR and can be combined 2 or 3 in series to have higher voltage.

One alternative is having multiple CR2032 in parallel, but with that configuration you need to be careful to avoid "charging non-rechargeable batteries". That means that all batteries need to be replaced with fresh ones at once, with the same brand. If there is a difference in the charge between the batteries, one will start charging the other, and that is not generally allowed. There should be an ideal diode between the batteries and the nPM2100 to prevent the current flowing to wrong direction. There's few words about that in our nPM2100 Reverse Battery Protection application note.

[quote user="Luiz Miranda"]An important point of reference is that the PCB will have an antenna chip and that we are aiming for a PCB with dimensions of 4.5 cm x 3.00 cm.[/quote]

These dimension would fit 3 pcs of AAA batteries. The nRF chip and the antenna needs special care during placement and routing, so look out for that. If you have a ready schematic and PCB design, we will review it to make sure that the nPM and nRF circuits and layouts are optimal.

This is all the help I can provide you now with your project, I hope it will be useful for you. If you have any specific questions regarding Nordic products, we are happy to assist you.

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Luiz Miranda — Thu, 21 May 2026 14:26:18 GMT

Hi Szabolcs:

We are developing a new commercial product based on the nRF54L15 SoC and managed by the nPM2100 PMIC. The device is powered by a CR2032 coin cell battery and features a critical acoustic alarm function using an externally driven passive piezoelectric transducer.

The piezo transducer we intend to use is:

Piezo element, Externally driven, Frequency: 4,0 kHz - 5,0 kHz, Voltage - Input (Max): 30V p-p, Impedance: 250 Ohms, Capacitance @ Frequency: 16000pF @ 120Hz, Size / Dimension: 1.063" Dia (27.00mm), Termination: Wire Leads (100 mm lead wire)

Observed Behavior & Test Setup:

We conducted bench tests using the nPM2100 EK powered by a brand new CR2032 battery (open-circuit voltage of 3.19V). We monitored the real-time power system metrics using the nPM Power UP tool within nRF Connect for Desktop.

The PMIC output ($V_{OUT}$) was configured to 3.0V. For the physical evaluation, we utilized a small reference PCB that already integrated the exact same passive cylindrical transducer we aim to qualify. Originally, this reference PCB is powered by 3x LR44 alkaline batteries (~4.5V), but we could not fully identify its discrete electronic driver components.

We modified this reference board to be powered directly by the 3.0V output from the nPM2100 EK. Upon triggering the alarm, the sound pressure level was loud and successfully met our target of 80 dB.

However, during this activation, we observed a severe voltage sag on the CR2032 battery due to the high internal impedance of the lithium cell. The CR2032 voltage dropped instantly to 1.89V during the first prolonged audio pulse, recovering very slowly after the pulse ended. In subsequent tests with the rail capacitors fully charged, the voltage drop stabilized at 2.65V. Additionally, we found that this reference board circuit completely fails to drive the buzzer if the nPM2100 $V_{OUT}$ is configured anywhere below 3.0V.

Our Objective:

Since the passive transducer requires an external oscillating signal and our final product will not use this external reference PCB, we plan to generate the 4 kHz to 5 kHz frequency directly using the nRF54L15 PWM peripheral. We need to design our own discrete driver circuit on our custom PCB to guarantee the same 80 dB output efficiently, without triggering a brownout reset (BOD) on the nRF54L15.

Our Questions for Support:

What are the official recommendations for the driver circuit topology (e.g., migrating to an N-channel MOSFET like the 2N7002, an H-bridge configuration, or sticking with a standard BJT) to safely and efficiently achieve 80 dB at 3.0V or below?

What are the ideal values and types of bulk/decoupling capacitors (low-ESR ceramic vs. electrolytic) recommended to shield the nPM2100 power rail from the heavy current ripples caused by the 4 kHz piezo PWM switching?

Are there any specific application notes or reference designs from Nordic combining the nPM2100 and passive piezo transducers operating on high-impedance coin cells (CR2032)?

Is it possible to achieve a minimum of 80dB with the CR2032? If not, which battery would be best? CR2450, for example CR2450?

An important point of reference is that the PCB will have an antenna chip and that we are aiming for a PCB with dimensions of 4.5 cm x 3.00 cm.

I have nRF54L15 DK, nPM2100 EK and Power Profiler kit II to make tests on protoboard.

Thank you in advance for your time and technical support during our project development.

Best regards,

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Szabolcs — Thu, 21 May 2026 08:54:55 GMT

Hi Luiz,

we can help, yes. What exactly is the problem, where did you get stuck? Can you share the schematic?

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Luiz Miranda — Wed, 20 May 2026 12:35:19 GMT

Hi Szabolcs:

I'm having trouble putting together an electrical schematic (components) to use the CR2032 with a piezo buzzer. The buzzer will sound 7 times a day for 10 seconds each time. Can Nordic help me find a solution?

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Szabolcs — Wed, 20 May 2026 10:15:48 GMT

Hi Luiz,

I'm glad to hear that it works. I'm afraid we don't have a ready solution to connect CR2450 to the EK. I think the best way would be to buy a battery holder and use jumper wires to connect to the input. You can use the CR2032 fuel gage model, as the chemistry of these batteries are identical.

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Luiz Miranda — Tue, 19 May 2026 16:09:12 GMT

Hi Szabolcs:

It's very easy, but I haven't read anything about the breaking procedure in other documentation.
Again, thank you!!

What is the best way to connect a CR2450 to the add-board?

Luiz

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Szabolcs — Tue, 19 May 2026 12:49:13 GMT

You need to break the battery holder board along the "mouse bites" (perforations). See image below. Break along the yellow holes to separate the battery board, or just break off the side along the green marks and discard it.

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Luiz Miranda — Tue, 19 May 2026 12:26:18 GMT

Hi:

See the photo I attached. How do I connect the male pins to the female pins?

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Szabolcs — Tue, 19 May 2026 09:44:01 GMT

Hi Luiz,

from what I can see from the pictures, the battery holder is connected the wrong way around. Please break the PCB out of the panel and connect it with the battery holder facing upwards (so that all the rubber pads are on the same side).

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Luiz Miranda — Fri, 15 May 2026 15:07:20 GMT

I replied the email with 3 photos.

RE: I CANNOT USE nPM 2100 EK WITH CR2023

aoliveri — Fri, 15 May 2026 14:56:59 GMT

Hi Luiz, you can email me the photos and I will forward them to DevZone

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Luiz Miranda — Fri, 15 May 2026 14:52:20 GMT

Thank you very much for your support and patience.

I can't understand the following:

The battery board is connected with nPM2100 EK.
There are two jumpers in VOUT and GND in TWI.
SW5 is in VBAT.
nPM2100 EK has no USB connection.
When I measure the voltage on the two jumpers, it shows 3.03 V.

I connect USB in nPM2100 EK.
Only one red LED lights up.
The battery model selected is CR2032 and the fuel gauge is enabled.

I tried attaching images with measurements of 320 x 240, but it gave an error.
I can send them by email.

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Szabolcs — Fri, 15 May 2026 08:09:12 GMT

Can you please share a photo of your setup and also a screenshot of nPM Power Up?

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Luiz Miranda — Thu, 14 May 2026 14:36:53 GMT

All LEDs are lit. One is red and all the others are green.
Switch is in VBAT.
But nPM Power UP does not detect the battery.
The battery model selected is CR2032 and the fuel gauge is enabled.

Battery Stats shows 2.96V.

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Szabolcs — Thu, 14 May 2026 13:06:34 GMT

Yes, if the switch is in the VBAT position, then the nPM will be powered by the battery. The USB will only power the controller MCU which monitors the nPM.

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Luiz Miranda — Thu, 14 May 2026 12:23:37 GMT

I will check the battery level.
I need to perform tests where the nPM2100 EK powers the VOUT pin (TW1) only with the CR2032.

Will the USB connection only be used for monitoring via the nPM Power UP?

RE: I CANNOT USE nPM 2100 EK WITH CR2023

Szabolcs — Thu, 14 May 2026 10:13:35 GMT

Hi Luiz,

what you described indicates that the charge level of the battery is low. Can you verify that the battery has full charge, is it a new battery?