Looking for a Zephyr expert for paid analysis / work

[raffiniert]

I would call this a success!

All it needed was this line in .conf:

CONFIG_FLASH=y

Thanks everyone here for the friendly help, I hope this will someday help someone else to not spend days for this

[msfujino]

I’m currently trying to run the nRF54L15 with Zephyr. For future reference, I’d really appreciate your help with the following:

1. Why does the current decrease when I enable the Flash driver by setting CONFIG_FLASH=y in prj.conf?
2. Could you show me the current waveform for 50 ms before and after the 10 mA peak current?

[raffiniert]

1. I can only suspect that the put flash to sleep command did not work because the flash was not enabled before - but this is unconfirmed and I need to review this later
2. of course, here you are:

overview:

just before the 10mA peak:

just after the 10mA peak:

[msfujino]

Thank you for the information.
The link below shows the current data from an experiment where 8 bytes were transferred every 10 seconds. For your reference!

System_ON_Sleep of XIAO BLE

I have considered a method to advertise a small amount of data (up to 24 bytes) added to the MSD(Manufacturer Specific Data) without connecting to Central. Peripheral advertises with data on them unilaterally, and Central retrieves it from the scan data without connection. The experimental conditions were BSP : Seeed nRF52 Boards 1.1.1 Board : Seeed nRF52 Boards / Seeed XIAO nRF52840 Sense System ON Sleep : Using RTOS delay() Task : Send 8 bytes of data every 10 seconds Current reduction m…

[daCoder]

Hi @raffiniert
Can you tell me if you explicitly suspended the flash in your code like below?

    // Put the peripheral into suspended state.
    int err = pm_device_action_run(qspi_dev, PM_DEVICE_ACTION_SUSPEND);

In the older versions of nrf connect I had to suspend the flash with ported arduino code. In my last go the above code was used. Maybe a recent update removes the need for explicit suspend of the flash. If so, I’ll update my example code. I’ll also double check that it doesn’t brick the xiao.

[raffiniert]

Payback time for all the help I got on this forum!

I try to document my cleanup of everything I’ve tried.

Removing this function in main() costs me 8uA:

static void qspi_flash_enter_dpd_and_park_pins(void)
{
/* Init QSPI long enough to talk to the chip */
nrfx_qspi_config_t cfg = NRFX_QSPI_DEFAULT_CONFIG(19, 17, 20, 21, 22, 23);
cfg.pins.sck_pin = 19;
cfg.pins.csn_pin = 17;
cfg.pins.io0_pin = 20;
cfg.pins.io1_pin = 21;
cfg.pins.io2_pin = 22;
cfg.pins.io3_pin = 23;

nrfx_qspi_init(&cfg, NULL, NULL);

/* Send Enter Deep Power-Down (0xB9) */
nrf_qspi_cinstr_conf_t cin = {
    .opcode   = 0xB9,
    .length   = NRF_QSPI_CINSTR_LEN_1B,
    .io2_level= true,
    .io3_level= true,
    .wipwait  = false,
    .wren     = false,
};
(void)nrfx_qspi_cinstr_xfer(&cin, NULL, NULL);

/* Done with QSPI */
nrfx_qspi_uninit();

/* Park pins to prevent leakage: CS high, others pulled down */
const struct device *gpio0 = DEVICE_DT_GET(DT_NODELABEL(gpio0));
gpio_pin_configure(gpio0, 17, GPIO_OUTPUT_HIGH);                 /* CS */
gpio_pin_configure(gpio0, 19, GPIO_INPUT | GPIO_PULL_DOWN);      /* SCK */
gpio_pin_configure(gpio0, 20, GPIO_INPUT | GPIO_PULL_DOWN);      /* IO0 */
gpio_pin_configure(gpio0, 21, GPIO_INPUT | GPIO_PULL_DOWN);      /* IO1 */
gpio_pin_configure(gpio0, 22, GPIO_INPUT | GPIO_PULL_DOWN);      /* IO2 */
gpio_pin_configure(gpio0, 23, GPIO_INPUT | GPIO_PULL_DOWN);      /* IO3 */

}

WIP