Electronics Design AUnRF5340 network core not starting — BLE stack hangs on bt_enable after migrating from nRF52840
Asked by stale_biscuit_03 ·
Trying to bring up an nRF5340 DK for the first time. I've done a few nRF52840 projects before so I figured the NCS migration would be fairly smooth — just change the board target, rebuild, done. Not quite.
I took my nRF52840 BLE peripheral project (Zephyr-based, NCS 2.6.1), updated the west build command to:
west build --pristine -b nrf5340dk/nrf5340/cpuapp .
Build completes with no errors. I flash with west flash. The LED in main()
blinks — so the app core is definitely running. I can see UART output from
printk(). But bt_enable() never returns. It just hangs. I'm waiting 30
seconds and nothing. No error, no callback, nothing.
My prj.conf is basically the same as my nRF52840 project:
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="MyDevice"
CONFIG_BT_MAX_CONN=1
CONFIG_UART_CONSOLE=y
I found a few Nordic DevZone posts hinting at something about the "network core" but couldn't work out what exactly I need to change. Is there a step I'm missing when moving from nRF52840 to nRF5340?
2 Replies
This is the classic nRF52-to-nRF5340 migration surprise, and it catches almost everyone the first time. The nRF5340 is fundamentally different from the nRF52840 in one critical way: it has two separate Cortex-M33 cores.
- Application core — up to 128 MHz, 1 MB Flash, 512 KB RAM. Runs your application firmware.
- Network core — up to 64 MHz, 256 KB Flash, 64 KB RAM. Runs the BLE/802.15.4 radio stack.
On the nRF52840, one image does everything — your application and the BLE stack
(via SoftDevice or Zephyr BLE) live on the same core. On the nRF5340, the BLE
controller firmware runs on the network core as a separate image called
hci_ipc. Your app core communicates with it over IPC (Nordic's Inter-Processor
Communication peripheral). When the network core doesn't have hci_ipc running,
the IPC channel is silent — bt_enable() sends the HCI reset command and waits
forever for a response that never comes.
The fix: add CONFIG_BT_HCI_IPC=y to your app core prj.conf
CONFIG_BT=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_DEVICE_NAME="MyDevice"
CONFIG_BT_MAX_CONN=1
CONFIG_UART_CONSOLE=y
CONFIG_BT_HCI_IPC=y
CONFIG_BT_HCI_IPC=y does two things:
- Configures the Zephyr BLE stack to use IPC as its HCI transport instead of directly controlling a local radio controller — which is how the nRF52840 works.
- Triggers the NCS child image build for the network core. When NCS sees
CONFIG_BT_HCI_IPC=ytargeting anrf5340/cpuappboard, it automatically includes thehci_ipcsample as a child image built fornrf5340/cpunet. Both images get compiled in onewest buildinvocation and both get flashed in onewest flash.
After adding that line, do a clean build:
west build --pristine -b nrf5340dk/nrf5340/cpuapp .
west flash
In the build output, you should now see two images being built — the main
application (cpuapp) and the network core child image (cpunet). If you only
see one image in the build output, something in the Kconfig isn't taking effect
— double-check with --pristine.
After flashing both images, bt_enable() should complete and BLE advertising
should start. The nRF52 vs nRF53 architecture guide
covers the dual-core model in more depth if you want to understand the IPC
mechanism beyond what's needed to get it working.
One other thing to check:
The nRF5 SDK (Nordic's older SDK, not NCS) does not support the nRF5340 at all. If any part of your project pulled in nRF5 SDK code or SoftDevice headers from an nRF52 project, strip those out — they're incompatible with nRF5340 and can cause confusing build errors or silent misconfiguration. NCS is mandatory for nRF5340.
Good summary above. A couple of additional points from the Infocenter docs.
Verifying the network core is actually running
After flashing, if BLE still doesn't start, you can confirm whether the network
core is executing by checking whether IPC is alive. The simplest way without a
second debug probe: look at the network core flash region using nrfjprog:
nrfjprog --coprocessor CP_NETWORK --readcode netcore.hex
If the hex is all 0xFF, the network core flash is blank — west flash didn't
write it, which means the child image wasn't built. Go back and confirm
CONFIG_BT_HCI_IPC=y is in effect with west build --pristine.
If the hex contains data but BLE still hangs, the IPC is failing at init. This is less common but can happen if there's a clock or domain configuration issue on a custom board (not the DK). On the DK itself, this shouldn't occur.
Nordic Infocenter reference
Nordic's nRF5340 application development guide
covers the dual-image build in detail, including how to use a pre-built network
core image if you don't want to rebuild hci_ipc every time (useful once your
app core is stable and you're iterating on app-only changes).
Migration from nRF52840 checklist
A few other things that typically need updating when porting an nRF52840 project:
- Board target:
nrf52840dk/nrf52840→nrf5340dk/nrf5340/cpuapp - Add
CONFIG_BT_HCI_IPC=y(as above) - Remove any
CONFIG_NFCT_*Kconfig if you were using NFC on the nRF52840 — the nRF5340 app core NFC peripheral is on a different pin mapping - DTS overlays referencing nRF52840-specific node paths will need updating;
the nRF5340 DK DTS is at
zephyr/boards/nordic/nrf5340dk/ - SoftDevice-specific Kconfig (
CONFIG_SOC_SERIES_NRF52X) is gone; NCS handles the radio stack entirely through the Zephyr BLE + hci_ipc path on nRF5340
The nRF5340 is a significant capability jump from the nRF52840 (LE Audio, higher BLE throughput, TrustZone), but the dual-core model means you need to think in two images from day one. Once you have the DK working, the NCS setup guide is worth rereading with nRF5340 specifically in mind — a few sections read differently once you know you're dealing with two cores.