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]

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?

[mento]

We disabled logging over RTT as suggested:

• CONFIG_USE_SEGGER_RTT=n

• CONFIG_CONSOLE=n

• CONFIG_PRINTK=n

We rebuilt (sysbuild with MCUboot), flashed, and tested without connecting RTT Viewer. The board still does not advertise until we connect J-Link RTT Viewer; after RTT Viewer connects, BLE advertising starts and we can see the device in nRF Connect.So the issue does not appear to be RTT buffer blocking (logging over RTT is disabled). We would appreciate any further suggestions or known workarounds for NCS v2.9.2 on a custom nRF52832 board without DCDC (LDO only, 32k RC). Thank you.

[Vidar Berg]

It is difficult to come up with a workaround when we don't now what the issue as. To debug this further, please read out the CPU registers from the device when it "hangs" using nrfjprog or nrfutil from the command line:

nrfutil device cpu-registers-read
nrfjprog --readregs

This may help us figure out what state the chip/fw is in when it fails to perform BLE advertising.

Have you tried replicating this issue on a Nordic development kit?

[mento]

We ran nrfjprog --readregs while the device was in the non-advertising state (RTT Viewer not connected). The register dump is below.

PS C:\ncs\v2.9.2\nrf\applications\ble_test> nrfjprog --readregs
R0: 0x00000000
R1: 0x00000000
R2: 0x00000000
R3: 0x00000000
R4: 0x00000000
R5: 0x00000000
R6: 0x00000000
R7: 0x00000000
R8: 0x00000000
R9: 0x00000000
R10: 0x00000000
R11: 0x00000000
R12: 0x00000000
SP: 0x20006100
LR: 0xFFFFFFFF
PC: 0x00002ADC
xPSR: 0x01000000
MSP: 0x20006100
PSP: 0x00000000
RAZ: 0x00000000
CFBP: 0x00000000
APSR: 0x00000000
EPSR: 0x01000000
IPSR: 0x00000000

[Vidar Berg]

The register readout is from early boot in the bootloader. Forgot to add that you should also build the bootloader and app with CONFIG_RESET_ON_FATAL_ERROR=n in case it is going in a boot loop. 

Vidar Berg said:

Have you tried replicating this issue on a Nordic development kit?

[mento]

PS C:\ncs\v2.9.2\nrf\applications\ble_test> nrfjprog --readregs
R0: 0x00000000
R1: 0x00000000
R2: 0x00000000
R3: 0x00000000
R4: 0x00000000
R5: 0x00000000
R6: 0x00000000
R7: 0x00000000
R8: 0x00000000
R9: 0x00000000
R10: 0x00000000
R11: 0x00000000
R12: 0x00000000
SP: 0x20006100
LR: 0xFFFFFFFF
PC: 0x00002ADC
xPSR: 0x01000000
MSP: 0x20006100
PSP: 0x00000000
RAZ: 0x00000000
CFBP: 0x00000000
APSR: 0x00000000
EPSR: 0x01000000
IPSR: 0x00000000



We have set CONFIG_RESET_ON_FATAL_ERROR=n in both the bootloader and the app, rebuilt and reflashed, then read the CPU registers again with the device in the non-advertising state (RTT Viewer not connected). The register dump is above.One more question: could you provide (or point to) a minimal NCS v2.9.2 sample configured for LDO only (no DCDC), e.g. a BLE advertising app with sysbuild and MCUboot? Having such a baseline would help us compare our setup. We use a custom nRF52832 board without DCDC. Thank you.

[Vidar Berg]

Attached is a minimal sample you can build for nrf52dk/nrf52832. It includes a Kconfig fragment that selects the internal RC oscillator as the LF clock source and a Devictree overlay to select the LDO regulator. I also included the merged.hex file in this so you can also program that instead of building the project yourself (It's built on SDK v3.2.1).

hello_world_ble_advertising.zip 

[mento]

Thank you for providing the minimal sample (hello_world_ble_advertising with LDO + 32kHz RC and merged.hex).

It was very helpful. After flashing it on our custom LDO-only board, we confirmed BLE advertising works without RTT connected. We then aligned our application (power_box) with the same approach—LDO via overlay, 32kHz RC, and CONFIG_LOG=y with RTT in non-blocking mode—and now our product also starts advertising after power-on without needing RTT Viewer.

We really appreciate having this reference; it made resolving the issue much easier.