## Summary
When running the OpenThread CLI sample on `nrf54lm20dk/nrf54lm20a/cpuapp` using nRF Connect SDK v3.2.4, the application crashes immediately on boot with a **precise BusFault** before any console output is produced.
After investigation, the fault occurs **inside the precompiled MPSL binary during `mpsl_init()`**, where the library accesses peripheral base addresses that are valid for **nRF54L15**, but **unmapped on nRF54LM20**.
Applications that do **not** use MPSL (for example `hello_world`) run correctly on the same board and SDK version.
This blocks **all radio‑based stacks** (Thread, Bluetooth LE, Zigbee, Matter, multiprotocol) on nRF54LM20 in the currently released SDKs.
This issue occurs inside the precompiled MPSL library during
mpsl_init() and is not specific to OpenThread; any MPSL‑based stack (BLE, Thread, Zigbee, Matter, multiprotocol) is affected.---
## Environment
| Item | Value |
|------|------|
| nRF Connect SDK | v3.2.4 |
| Board | nRF54LM20‑DK |
| Board target | `nrf54lm20dk/nrf54lm20a/cpuapp` |
| Sample | `nrf/samples/openthread/cli` (unmodified) |
| Toolchain | SDK default |
| Debug probe | J‑Link |
| SoC | nRF54LM20A |
---
## Observed behavior
- Device resets and hard‑faults immediately after boot
- No UART output (fault happens before console init)
- CPU halts in `arch_system_halt()` after a BusFault
- The failure only occurs when MPSL is enabled (Thread / BLE / radio stacks)
---
## Fault analysis
The BusFault is triggered during `mpsl_init()` when the MPSL binary attempts to access the **ECB00 peripheral** using an address that is valid on nRF54L15 but **not mapped on nRF54LM20**.
### Example faulting access
- Accessed address: `0x50047004`
- This corresponds to `NRF_ECB00_S_BASE + 0x4` **for nRF54L15**
- On nRF54LM20, ECB00 is located at `0x5004B000`, and `0x50047000` is unmapped
The fault is a **precise BusFault** with `BFARVALID=1` and `PRECISERR=1`.
### Register snapshot (at `z_arm_fault()` entry)
```
CFSR = 0x00008200 (BFARVALID | PRECISERR)
BFAR = 0x50047004
R3 = 0x50047000
PC = mpsl_init → obfuscated MPSL function
```
---
## SoC peripheral base address differences (example subset)
| Peripheral | nRF54L15 | nRF54LM20 |
|-----------|---------|-----------|
| ECB00_S | `0x50047000` | `0x5004B000` |
| AAR00_S / CCM00_S | `0x50046000` | `0x5004A000` |
| KMU_S | `0x50045000` | `0x50049000` |
| CRACEN_S | `0x50048000` | `0x50059000` |
The addresses above are taken from the MDK headers:
- `nrf54l15_global.h`
- `nrf54lm20a_enga_global.h`
---
## Why this appears to be an MPSL packaging issue
The MPSL library selection is controlled by:
```
config MPSL_LIB_DIR
default "nrf54l" if SOC_SERIES_NRF54LX
```
Both **nRF54L15** and **nRF54LM20** fall under `SOC_SERIES_NRF54LX`, so they use the same precompiled MPSL binary (`nrfxlib/mpsl/lib/nrf54l/soft-float/libmpsl.a`).
However, the peripheral address map differs between the two SoCs. The current MPSL binary appears to have **nRF54L15 addresses baked in**, which leads to invalid accesses on nRF54LM20.
There is currently no `nrf54lm20`‑specific MPSL binary in released SDKs (checked through v3.3.0‑preview).
---
## Related prior DevZone issue (MPSL on nRF54L)
There is an earlier Nordic DevZone thread documenting **hard‑faults during MPSL init on nRF54L15**, attributed to MPSL internals and early‑boot behavior:
- **“nRF54L15 MPSL init stack corruption”**
Nordic DevZone Q&A (Feb 2025)
Although the root cause in that thread is different (interrupt timing / stack usage rather than peripheral addresses), it similarly demonstrates that:
- The failure occurs inside `mpsl_init`
- The root cause is internal to the precompiled MPSL binary
- There is no application‑level workaround
This suggests MPSL behavior is **SoC‑specific within the nRF54L family**, and that a single binary may not be suitable for all variants.
---
## Test coverage note
The OpenThread CLI sample is marked as `build_only` for nRF54LM20 targets. As a result:
- The sample compiles successfully
- The runtime fault is not exercised in CI
- The issue only becomes visible when flashing and running on hardware
---
## Workarounds
There does not appear to be a source‑level workaround, since the faulting code resides in a precompiled, obfuscated MPSL binary.
Current options are:
1. Use another SoC (e.g. nRF5340) for Thread / radio development
2. Avoid MPSL‑based stacks on nRF54LM20 for now
3. Await an updated MPSL library that explicitly supports nRF54LM20
---
## Request
Could you please confirm whether:
- nRF54LM20 is expected to require a **separate MPSL binary** from nRF54L15, and
- an updated MPSL build for nRF54LM20 is planned in an upcoming nRF Connect SDK release?
If additional traces or test projects are helpful, I can provide them.
Thank you.
