Hello
nPM Power UP v 2.24 detects nPM2100 EK, but does not detect the CR2032 battery.
The active battery model selected is CR2032 and the fuel gauge is enabled.
I placed the CR2032 in the battery holder and connected it to Battery Input Connector on EK.
Two LEDs light up side by side: a red LED and a yellow LED.
I tested it with SW5 for VEXT and VBAT.
I have read this link.www.nordicsemi.com/.../Get-started
Regards
Luiz Miranda
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?
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?
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,
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.
Luiz Miranda said: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?
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.
Luiz Miranda said: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?
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...
Luiz Miranda said: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)?
No, unfortunately, we don't have anything like that.
Luiz Miranda said:Is it possible to achieve a minimum of 80dB with the CR2032? If not, which battery would be best? CR2450, for example CR2450?
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.
Luiz Miranda said: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.
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.
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
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:
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:
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
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:
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
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.
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
#include <zephyr/kernel.h>
#include <zephyr/drivers/pwm.h>
#include <zephyr/logging/log.h>
LOG_MODULE_REGISTER(buzzer_app, LOG_LEVEL_INF);
/* Obtém as propriedades do nó criado no app.overlay */
static const struct pwm_dt_spec buzzer = PWM_DT_SPEC_GET(DT_ALIAS(buzzer_pwm));
int main(void)
{
LOG_INF("A iniciar sistema de PWM para o Buzzer (4 kHz)");
if (!pwm_is_ready_dt(&buzzer)) {
LOG_ERR("Erro: O periférico PWM não está pronto.");
return 0;
}
/* O Zephyr carrega automaticamente o valor de PWM_USEC(250) em nanosegundos (250.000 ns) */
uint32_t period = buzzer.period;
/* 50% de duty cycle = metade do período */
uint32_t pulse = period / 2;
LOG_INF("Período lido: %u ns. Ciclo de trabalho: %u ns.", period, pulse);
/* Envia a configuração para o hardware. A partir deste momento, o sinal é contínuo */
int err = pwm_set_dt(&buzzer, period, pulse);
if (err) {
LOG_ERR("Falha ao configurar o sinal PWM. Erro: %d", err);
return 0;
}
LOG_INF("Sinal ativo no pino P1.04. O processador principal vai entrar em suspensão.");
/* O periférico de hardware funciona de forma assíncrona.
* O loop principal não necessita de intervir.
*/
while (1) {
k_sleep(K_SECONDS(10));
}
return 0;
}