System / BLE only starts after J-Link RTT is connected (custom board, no DCDC) – fixed in NCS v2.5.1, same issue again in v2.9.2

[mento]

Hello,I am using a custom nRF52832-based board that has no DCDC circuitry (LDO only).What happened in NCS v2.5.1

• After power-on, the system did not start (e.g. no BLE advertising).

• The system only started after I connected J-Link RTT Viewer to the board.

• I spent a lot of time adjusting configuration (DCDC, clocks, RTT/console, etc.) and eventually got it working so that the system starts correctly after power-on without the debugger connected.

What happened after upgrading to NCS v2.9.2

• I upgraded to NCS v2.9.2 because v2.5.1 does not support ANT.

• The same problem came back: the system does not start on power-on; it only starts after I connect J-Link RTT Viewer to the board.

• I have tried to apply the same settings that fixed the issue in v2.5.1 (disabling DCDC in software, 32 kHz internal RC, disabling RTT / console, delays before BLE init, etc.), but the problem persists in v2.9.2.

Question

• What changed between NCS v2.5.1 and v2.9.2 that could cause this “no start until RTT is connected” behavior again on a custom board without DCDC?

• Is there any recommended configuration or workaround for NCS v2.9.2 so that the system (and BLE) starts reliably after power-on without requiring J-Link RTT to be connected?

Thank you for your help.

[Vidar Berg]

Hello,

The initial regulator mode is now defined in the devictree and if you are using the nrf52dk as your build target, the DCDC regulator will be enabled by default (https://docs.nordicsemi.com/bundle/ncs-3.1.1/page/zephyr/releases/migration-guide-4.0.html#regulator, https://github.com/nrfconnect/sdk-zephyr/blob/a0e545cb437a44b6f9cd176ef28a055403f8d2d8/boards/nordic/nrf52dk/nrf52dk_nrf52832.dts#L138)

You can include the following in your devicetree overlay to select the LDO:

&reg {
	regulator-initial-mode = <NRF5X_REG_MODE_LDO>;
};

 

Best regards,

Vidar

[mento]

I added the devicetree overlay with &reg { regulator-initial-mode = <NRF5X_REG_MODE_LDO>; }; as suggested. BLE still only starts after J-Link RTT is connected. On the same custom board (no DCDC), the same approach worked in NCS v2.5.1. Is there any other change in v2.9.2 (init order, clock, or regulator driver) that could cause this? Thank you.

[Vidar Berg]

Does your project include other FW images in the build such as MCUBoot? In that case, are you applying the overlays to those images as well?

[mento]

Yes. The project uses sysbuild and includes MCUBoot. We applied the LDO overlay to the application (boards/nrf52dk_nrf52832.overlay with &reg { regulator-initial-mode = <NRF5X_REG_MODE_LDO>; };) as you suggested. For MCUBoot, we tried adding the same overlay in sysbuild/mcuboot/boards/nrf52dk_nrf52832.overlay, but the MCUBoot CMake configure then failed, so we are not using a devicetree overlay for MCUBoot. We also tried CONFIG_BOARD_ENABLE_DCDC=n in child_image/mcuboot.conf, but that caused a configure failure (this board/Kconfig may not define that option). So at the moment only the application uses the LDO overlay and in-code DCDC disable; MCUBoot uses the board default. BLE still only starts after J-Link RTT is connected; without RTT it does not start. Could you advise how to apply the regulator (LDO) overlay to the MCUBoot image correctly in sysbuild, or whether applying it only to the application is sufficient for a custom board without DCDC? Thank you.

[Vidar Berg]

mento said:

n sysbuild/mcuboot/boards/nrf52dk_nrf52832.overlay, but the MCUBoot CMake configure then failed, so we are not using a devicetree overlay for MCUBoot. We

For this to work you must also provide the sysbuild/mcuboot/prj.conf file to replace the default prj.conf file from the mcuboot module. Another alternative to this is to remove the mcuboot directory in sysbuild and replace it with an overlay named mcuboot.overlay (Ref. https://docs.nordicsemi.com/bundle/ncs-2.6.1/page/zephyr/build/sysbuild/index.html#zephyr_application_kconfig_fragment_and_devicetree_overlay). 

[mento]

Thank you, Vidar.

We applied your alternative: we removed the sysbuild/mcuboot/ directory and added sysbuild/mcuboot.overlay with the LDO regulator overlay. The application already uses boards/nrf52dk_nrf52832.overlay with the same LDO setting. We also disable DCDC in code (EARLY and PRE_KERNEL_1 init, and again in main() before bt_enable() with a 150 ms delay). 32 kHz is set to internal RC (CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y, CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n).

Result: BLE still only starts advertising after J-Link RTT Viewer is connected; without RTT it does not start. On the same custom board (no DCDC hardware), the same approach worked in NCS v2.5.1 after we fixed it there.

We have attached our current configuration and code snippets below for reference. Could you advise what else might differ between v2.5.1 and v2.9.2 (e.g. init order, regulator driver, or clock) that could cause this "start only with RTT connected" behavior on a custom board without DCDC? Thank you.



1. prj.conf (excerpt)

CONFIG_NCS_SAMPLES_DEFAULTS=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n

CONFIG_BT=y

CONFIG_BT_PERIPHERAL=y

CONFIG_BT_DEVICE_NAME="BLE_Test_NCS29"

CONFIG_BT_MAX_CONN=1

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048

2. boards/nrf52dk_nrf52832.overlay

&reg {

    regulator-initial-mode = <NRF5X_REG_MODE_LDO>;

};

3. sysbuild/mcuboot.overlay

&reg {

    regulator-initial-mode = <NRF5X_REG_MODE_LDO>;

};

4. main.c (DCDC disable + BLE init excerpt)

#define NRF52_POWER_DCDCEN_ADDR  (0x40000578UL)

static int early_disable_dcdc_early(void) {

    *(volatile uint32_t *)NRF52_POWER_DCDCEN_ADDR = 0;

    __DSB(); __ISB(); return 0;

}

static int early_disable_dcdc_pre_kernel(void) {

    *(volatile uint32_t *)NRF52_POWER_DCDCEN_ADDR = 0;

    __DSB(); __ISB(); return 0;

}

SYS_INIT(early_disable_dcdc_early, EARLY, 0);

SYS_INIT(early_disable_dcdc_pre_kernel, PRE_KERNEL_1, 0);

int main(void) {

    int err;

    *(volatile uint32_t *)NRF52_POWER_DCDCEN_ADDR = 0;

    __DSB(); __ISB();

    k_sleep(K_MSEC(150));

    err = bt_enable(NULL);

    // ... then bt_le_adv_start()

}

5. sysbuild.conf

SB_CONFIG_BOOTLOADER_MCUBOOT=y

6. child_image/mcuboot.conf (excerpt)

CONFIG_MULTITHREADING=y

CONFIG_FLASH=y

CONFIG_FLASH_PAGE_LAYOUT=y

CONFIG_LOG=y

CONFIG_LOG_MODE_IMMEDIATE=y

CONFIG_BOOT_BANNER=y

CONFIG_BOOT_UPGRADE_ONLY=y

CONFIG_BOOT_DIRECT_XIP=n

CONFIG_BOOT_SWAP_USING_MOVE=n

[Vidar Berg]

The code changes to not init the DCDC shall be redundant since you are selecting LDO in the devictree. Next step I recommend is to check the output files to confirm that the correct configurations are applied to both mcuboot and app. 

- build/mcuboot/zephyr/.config  <- Does it include CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

- build/mcuboot/zephyr/zephyr.dts <- Check regulator node to confirm initial mode is set to NRF5X_REG_MODE_LDO (0)

mento said:

6. child_image/mcuboot.conf (excerpt)

The "child_image" directory must be renamed to "sysbuild" to be detected by the build. 

[mento]

We applied your suggestions:

• Using sysbuild with MCUboot (config under sysbuild/, no child_image).

• App: boards/nrf52dk_nrf52832.overlay with &reg { regulator-initial-mode = <NRF5X_REG_MODE_LDO>; };.

• MCUboot: sysbuild/mcuboot.conf (with CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y) and sysbuild/mcuboot.overlay with the same LDO setting.

• We verified the build:

• build/mcuboot/zephyr/.config contains CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y.

• build/mcuboot/zephyr/zephyr.dts has regulator-initial-mode = < 0x0 > (LDO).

Observation: When we connect J-Link RTT Viewer after power-on (or after west flash), we then see the MCUboot boot log in RTT and BLE advertising starts (we can see the device in nRF Connect). When RTT Viewer is not connected, we do not see BLE advertising.Important clarification: During west flash, RTT Viewer is disconnected, so we do not know whether:

• the device already ran (MCUboot + app) before RTT connected and we are just reading buffered RTT output and BLE was already on, or

• the device only runs or progresses after RTT Viewer connects, so boot log and BLE start together when RTT connects.

So we are not claiming that MCUboot runs normally and only BLE waits for RTT; we only know that without RTT Viewer connected we never see BLE advertising, and with RTT connected we see both the MCUboot boot messages and BLE. We’d like to know if there is a known workaround or further debug steps for NCS v2.9.2 on a custom nRF52832 board without DCDC.

[Vidar Berg]

Thanks for confirming. What you are observing is a common symptom of having the DCDC regulator enabled without the proper DCDC inductors included in the design. However, since you are correctly selecting the LDO regulator, it must be caused by something else in your case. It is possible to configure RTT to become blocking when the log buffer is full. Does the board advertise if you disable logging over RTT?