nRF5 SDK System power off MODE wake up issue.

[Theja]

Hi,

I'm working on an application where the system should enter System OFF mode after some button activity and wake up (restart) on a button press or USB connection.

When I flash the application using Segger Embedded Studio, it works as expected. However, when I flash the combined HEX file (containing the bootloader, application, and SoftDevice) generated using the post-build commands, it only wakes up from the button press. If I connect the USB while in System OFF mode, it enters an unknown state where nothing functions.

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.

Here are the post-build commands I'm using:
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

How can I resolve this issue? Any insights would be greatly appreciated.

Regards,
Theja.

[Vidar Berg]

Hello Theja,

If I connect the USB while in System OFF mode, it enters an unknown state where nothing functions.

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.

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.

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

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

Is there a flash command that comes after this?

Thanks,

Vidar

[Theja]

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.POWER_SCH (1).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){}
    }

[Theja]

Hi,

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

[Vidar Berg]

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.

[Theja]

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.

[Vidar Berg]

Theja said:

We're not using any custom bootloader

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

Theja said:

The pin you marked is used to detect the battery charging status—whether it's charging or fully charged.

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

Theja said:

I also tried setting NRF_BL_DFU_ENTER_METHOD_BUTTON=0 in the preprocessor, but the issue still persists.

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.

[Theja]

Hi,

Vidar Berg said:

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

Yes!

Vidar Berg said:

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.

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.

[Vidar Berg]

Theja said:

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.

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.

[Theja]

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

[Vidar Berg]

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.