I CANNOT USE nPM 2100 EK WITH CR2023

[Luiz Miranda]

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

[Szabolcs]

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?

[Luiz Miranda]

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?

[Luiz Miranda]

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

[Szabolcs]

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:

1. 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
2. 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.

[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:

• 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

[Szabolcs]

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.

[Luiz Miranda]

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:

1. 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?

2. 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?

3. 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?

4. 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

6471.app.overlay

Fullscreen 44273.main.c Download

#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;
}

8272.prj.conf