nRF5 SDK System power off MODE wake up issue.

RE: nRF5 SDK System power off MODE wake up issue.

Theja — Thu, 24 Apr 2025 06:18:05 GMT

Hi Berg,

Thank you for your assistance. It worked perfectly! and I truly appreciate your support!

Regards,
Theja

RE: nRF5 SDK System power off MODE wake up issue.

Vidar Berg — Wed, 23 Apr 2025 07:30:41 GMT

The device will always wake up from system OFF when voltage is detected on the VBUS. The problem seems to be that the bootloader is entering DFU mode after it wakes up from System OFF. Likely because you still have the NRF_BL_DFU_ENTER_METHOD_BUTTON flag enabled in your bootloader's sdk_config header.

RE: nRF5 SDK System power off MODE wake up issue.

Theja — Wed, 23 Apr 2025 07:25:02 GMT

[quote userid="126494" url="~/f/nordic-q-a/120350/nrf5-sdk-system-power-off-mode-wake-up-issue/532475"]I just wanted to is there any USB configurations are required to wake from USB VBUS[/quote]

What about this?

RE: nRF5 SDK System power off MODE wake up issue.

Vidar Berg — Wed, 23 Apr 2025 05:22:30 GMT

Please upload the sdk_config.h file for your bootloader project here.

RE: nRF5 SDK System power off MODE wake up issue.

Theja — Wed, 23 Apr 2025 05:15:46 GMT

I didn't find that command in sdk_config.h, and I just wanted to is there any USB configurations are required to wake from USB VBUS? If so kindly let me know.

RE: nRF5 SDK System power off MODE wake up issue.

Vidar Berg — Tue, 22 Apr 2025 12:56:30 GMT

The original bootloader code will only configure this pin as an input if NRF_BL_DFU_ENTER_METHOD_BUTTON is enabled in sdk_config.h.

RE: nRF5 SDK System power off MODE wake up issue.

Theja — Tue, 22 Apr 2025 12:35:49 GMT

I tried reading that gpio resgister got "0003000C" as a response indicating it's in input.

RE: nRF5 SDK System power off MODE wake up issue.

Vidar Berg — Tue, 22 Apr 2025 12:19:28 GMT

[quote userid="126494" url="~/f/nordic-q-a/120350/nrf5-sdk-system-power-off-mode-wake-up-issue/532336"]I searched for the sd_app_evt_wait() function throughout the entire project and found it in nrf_pwr_mgmt.c. I also tried commenting out the call to this function, but the issue still persists.[/quote]

This was to help troubleshoot the problem. Where is the Program counter (PC) at after you commented this function? You may also want to read the GPIO configuration register to confirm that P0.25 is not configured as an input.

RE: nRF5 SDK System power off MODE wake up issue.

Theja — Tue, 22 Apr 2025 12:17:10 GMT

Hi,

[quote userid="4240" url="~/f/nordic-q-a/120350/nrf5-sdk-system-power-off-mode-wake-up-issue/532303"]Is this signal is asserted when you have the USB cable inserted?[/quote]

Yes!

[quote userid="4240" url="~/f/nordic-q-a/120350/nrf5-sdk-system-power-off-mode-wake-up-issue/532303"]Then you can comment the wait for event function in the bootloader and read the CPU regs again to find out why it hangs in the bootloader.[/quote]

I searched for the sd_app_evt_wait() function throughout the entire project and found it in nrf_pwr_mgmt.c. I also tried commenting out the call to this function, but the issue still persists.

RE: nRF5 SDK System power off MODE wake up issue.

Vidar Berg — Tue, 22 Apr 2025 10:02:15 GMT

[quote userid="126494" url="~/f/nordic-q-a/120350/nrf5-sdk-system-power-off-mode-wake-up-issue/532300"]We're not using any custom bootloader[/quote]

No, but you may need to adapt the configuration for your board.

[quote userid="126494" url="~/f/nordic-q-a/120350/nrf5-sdk-system-power-off-mode-wake-up-issue/532300"]The pin you marked is used to detect the battery charging status—whether it's charging or fully charged.[/quote]

Is this signal is asserted when you have the USB cable inserted?

[quote userid="126494" url="~/f/nordic-q-a/120350/nrf5-sdk-system-power-off-mode-wake-up-issue/532300"]I also tried setting NRF_BL_DFU_ENTER_METHOD_BUTTON=0 in the preprocessor, but the issue still persists.[/quote]

Then you can comment the wait for event function in the bootloader and read the CPU regs again to find out why it hangs in the bootloader.

RE: nRF5 SDK System power off MODE wake up issue.

Theja — Tue, 22 Apr 2025 09:47:39 GMT

Hi,

We're not using any custom bootloader; we're using ble_dfu for our applications, and it's working as expected.
The pin you marked is used to detect the battery charging status—whether it's charging or fully charged.
I also tried setting NRF_BL_DFU_ENTER_METHOD_BUTTON=0 in the preprocessor, but the issue still persists.

RE: nRF5 SDK System power off MODE wake up issue.

Vidar Berg — Tue, 22 Apr 2025 08:48:07 GMT

Hi,

Everything indicates that it enters DFU mode after wake up. In your bootloader project's sdk_config.h header, please ensure that NRF_BL_DFU_ENTER_METHOD_BUTTON is not enabled. By default, it is enabled on pin P0.25, which I see is connected to a charge status signal in your schematic.

RE: nRF5 SDK System power off MODE wake up issue.

Theja — Tue, 22 Apr 2025 07:45:21 GMT

Hi,

Our requiremnt is to wake the device immediately after USB connection.

RE: nRF5 SDK System power off MODE wake up issue.

Theja — Tue, 22 Apr 2025 07:38:31 GMT

[quote userid="126494" url="~/f/nordic-q-a/120350/nrf5-sdk-system-power-off-mode-wake-up-issue/532275"]During the failure cases, even though the device doesn’t wake immediately after USB connection, it eventually wakes up after some time and then operates as expected.[/quote]

Means, It enters to application.

RE: nRF5 SDK System power off MODE wake up issue.

Theja — Tue, 22 Apr 2025 07:37:45 GMT

Hi,

[quote userid="4240" url="~/f/nordic-q-a/120350/nrf5-sdk-system-power-off-mode-wake-up-issue/532271"]I'm asking about the failing case. [/quote]

During the failure cases, even though the device doesn’t wake immediately after USB connection, it eventually wakes up after some time and then operates as expected.

If you'd like to check whether the device is in DFU mode during that unknown state, could you please advise on how I can verify that?

RE: nRF5 SDK System power off MODE wake up issue.

Vidar Berg — Tue, 22 Apr 2025 07:29:36 GMT

[quote userid="126494" url="~/f/nordic-q-a/120350/nrf5-sdk-system-power-off-mode-wake-up-issue/532264"]No, after waking up, it enters the application and works as expected.[/quote]

I'm asking about the failing case.

RE: nRF5 SDK System power off MODE wake up issue.

Theja — Tue, 22 Apr 2025 07:17:53 GMT

Hi,

[quote userid="4240" url="~/f/nordic-q-a/120350/nrf5-sdk-system-power-off-mode-wake-up-issue/532250"]Are you able to check if the device may be entering bootloader DFU mode after the wake up?[/quote]

No, after waking up, it enters the application and works as expected.

To ensure we're on the same page, let me repeat the issue we're facing:

Using a button action, I put the device into deep sleep (system OFF mode). Before entering deep sleep, I configure the button as a wake-up source.

The problem is that after entering deep sleep, when I connect the USB, the device wakes up immediately in some cases, but other times it takes over 5 minutes to wake up (the timing varies). Once the device wakes up—even after the delay—it works as expected.

I’ve attached the deep sleep-related code for your reference.

void enter_deepSleep()
{
    ret_code_t  err_code;
    
    nrf_gpio_pin_clear(SHDN);
    nrf_gpio_cfg_input(SHDN, NRF_GPIO_PIN_NOPULL);

    nrf_drv_gpiote_in_uninit(BUTTON_PIN_NO);             //UnInitialize the wake-up pin

    turn_off_LED(GREEN);
    turn_off_LED(BLUE);
    turn_off_LED(RED);
   
    nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_TOGGLE(false);     //Configure to generate interrupt and wakeup on pin signal low. "false" means that gpiote will use the PORT event, which is low power, i.e. does not add any noticable current consumption (<<1uA). Setting this to "true" will make the gpiote module use GPIOTE->IN events which add ~8uA for nRF52 and ~1mA for nRF51.
    in_config.pull = NRF_GPIO_PIN_PULLUP;                                            //Configure pullup for input pin to prevent it from floting. Pin is pulled down when button is pressed on nRF5x-DK boards, see figure two in http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52/dita/nrf52/development/dev_kit_v1.1.0/hw_btns_leds.html?cp=2_0_0_1_4
   
    err_code = nrf_drv_gpiote_in_init(BUTTON_PIN_NO, &in_config, NULL);             //Initialize the wake-up pin
    APP_ERROR_CHECK(err_code);                                                       //Check error code returned
    
    nrf_drv_gpiote_in_event_enable(BUTTON_PIN_NO, true);                            //Enable event and interrupt for the wakeup pin   
    
    //StartBlinkTimer(BlinkThrice);
    nrf_delay_ms(2000);
    NRF_POWER->SYSTEMOFF = 1;
}

Also, please note that I haven’t done any explicit USB wake-up configuration during deep sleep, as the controller is already connected to USB VBUS.

regards,
Theja

RE: nRF5 SDK System power off MODE wake up issue.

Vidar Berg — Tue, 22 Apr 2025 06:36:30 GMT

Hi,

The readout shows that the program has entered the wait for event loop inside the softdevice which is where a typical application will spent most of its time in. This loop is entered when the application or bootloader calls sd_app_evt_wait(). Are you able to check if the device may be entering bootloader DFU mode after the wake up?

RE: nRF5 SDK System power off MODE wake up issue.

Theja — Tue, 22 Apr 2025 05:41:55 GMT

Hi,

Apologies for the delayed response. I’ve read the registers while the device was in the unknown state, and I’ve attached the data below for your reference.

R0: 0x00025F40
R1: 0x2003FFB8
R2: 0x00000000
R3: 0x00000000
R4: 0x200000B8
R5: 0x00000000
R6: 0xE000E000
R7: 0x00000000
R8: 0x00000000
R9: 0x00000000
R10: 0x00000000
R11: 0x00000000
R12: 0x2003FF80
SP: 0x2003FFB8
LR: 0x0001671D
PC: 0x00025F40
xPSR: 0x61000000
MSP: 0x2003FFB8
PSP: 0x00000000
RAZ: 0x00000000
CFBP: 0x00000000
APSR: 0x60000000
EPSR: 0x01000000
IPSR: 0x00000000

Also, please note a few changes compared to previous observations. The device tends to enter the unknown state after being connected to USB. This behavior appears to be random and is not specific to the IDE or the hex file — it's occurring in both cases approximately 5 to 6 times out of 10.

I’ve also attached the schematic for your reference.devzone.nordicsemi.com/.../POWER_5F00_SCH-_2800_1_2900_.pdf

To set the GPIO output to 3.3V, I made the following changes. Could this have anything to do with the issue?

    {
        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Wen;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}

        NRF_UICR->REGOUT0 = (NRF_UICR->REGOUT0 & ~((uint32_t)UICR_REGOUT0_VOUT_Msk)) |
                            (UICR_REGOUT0_VOUT_3V3 << UICR_REGOUT0_VOUT_Pos);  

        NRF_NVMC->CONFIG = NVMC_CONFIG_WEN_Ren;
        while (NRF_NVMC->READY == NVMC_READY_READY_Busy){}
    }

RE: nRF5 SDK System power off MODE wake up issue.

Vidar Berg — Tue, 01 Apr 2025 12:34:52 GMT

Hello Theja,

[quote user=""]If I connect the USB while in System OFF mode, it enters an unknown state where nothing functions.[/quote]

Please run 'nrfjprog --readregs' when the chip is in this state to see if the register readout may reveal what state the device is in.

[quote user=""]I compared the HEX files — one read back from the device (flashed via IDE) and the other generated through the post-build commands — and found differences.[/quote]

Does the application region in flash contain different data when you check the flash contents after using these two different methods?

nrfjprog --memrd 0x0 --n 0x1000000 > memory_content.txt

[quote user=""]call nrfutil settings generate --family NRF52840 --application CenSyn_EEG.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 bootloader_settings.hex
call mergehex --merge bootloader_settings.hex secure_bootloader.hex --output Combined_bootloader.hex
call mergehex --merge s140_nrf52_7.2.0_softdevice.hex Combined_bootloader.hex --output SD_FBL.hex
call mergehex --merge CenSyn_EEG.hex SD_FBL.hex --output Final_Hex.hex
call nrfutil pkg generate --hw-version 52 --application-version 2 --application CenSyn_EEG.hex --sd-req 0x100 --key-file private.key CenSyn_EEG_DFU.zip[/quote]

Is there a flash command that comes after this?

Thanks,

Vidar