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?

[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

[Szabolcs]

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.