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.

[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.

[Vidar Berg]

Glad to hear that you were able to identify the problem, thanks for the update. I thought we had eliminated this potential problem earlier when you disabled RTT, guess maybe it wasn't disabled in the bootloader.