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,

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