Bus faults with xiao nrf54l15?

Products & Technology XIAO
,
5

Hi there,

So I ran this past my rep’s engineer and confirmed it with the AI,
the general consensus is The "LOGGING is Notorious for faults , check the forum…as well.
But You’re likely seeing a debug+logging-induced timing/stack issue, not flaky HW. Several things in that prj.conf can push Zephyr over the edge on nRF54L15—especially CONFIG_LOG_MODE_IMMEDIATE=y, high log level, and small/default stacks. Immediate logging runs in the caller’s context (often ISR), which is notorious for tripping faults on Nordic targets when combined with heavy debug builds. Zephyr Project Documentation+2Nordic Semiconductor Docs+2

What I’d try (in this order)

  1. Go deferred logging
  • CONFIG_LOG=y
  • CONFIG_LOG_MODE_IMMEDIATE=n
  • CONFIG_LOG_PROCESS_THREAD=y
  • CONFIG_LOG_PROCESS_THREAD_SLEEP_MS=10
  • Drop the global level to INFO while testing: CONFIG_LOG_DEFAULT_LEVEL=3
    Rationale: avoids ISR-context logging + reduces pressure. Zephyr Project Documentation
  1. Bump stacks (debug builds use more stack)
  • CONFIG_MAIN_STACK_SIZE=2048
  • CONFIG_ISR_STACK_SIZE=2048
  • CONFIG_IDLE_STACK_SIZE=512
  • Keep: CONFIG_STACK_SENTINEL=y (or your CONFIG_MPU_STACK_GUARD=y, but note alignment/size constraints and that guard can fault sooner with tight stacks). Zephyr Project Documentation
  1. Trim “heavy” debug toggles
  • Temporarily disable: CONFIG_DEBUG_THREAD_INFO, CONFIG_DEBUG_OPTIMIZATIONS, maybe even CONFIG_ASSERT just to confirm sensitivity—then re-enable one by one.
  1. Console backend sanity
  • If you’re using RTT: CONFIG_USE_SEGGER_RTT=y, CONFIG_LOG_BACKEND_RTT=y.
  • If UART: keep RTT off to avoid two backends fighting.
  1. Re-test on NCS 3.1.1
    3.1.1 does fix a handful of 3.1.0 paper cuts; several folks report better stability on 3.1.1 with the Xiao/54L15. (Your forum thread lines up with that trajectory.) Seeed Studio Forum
  2. If still flaky, A/B the guard
  • Try without CONFIG_MPU_STACK_GUARD to see if it’s just catching undersized stacks (then restore it after tuning). Guarded stacks on Cortex-M require stricter alignment/size and can surface marginal configs as “bus faults.” Zephyr Project Documentation

Why I think it’s this

  • The user can reproduce only with DEBUG enabled, and even Blinky trips it. That screams context/timing/stack rather than GPIO.
  • Immediate logging in ISR context has a track record of crashes on Nordic targets when debug is on and stacks are tight.

Try something along these lines…

# Core
CONFIG_GPIO=y

# Logging (deferred)
CONFIG_LOG=y
CONFIG_LOG_DEFAULT_LEVEL=3
CONFIG_LOG_MODE_IMMEDIATE=n
CONFIG_LOG_PROCESS_THREAD=y
CONFIG_LOG_PROCESS_THREAD_SLEEP_MS=10
CONFIG_LOG_BACKEND_RTT=y
CONFIG_USE_SEGGER_RTT=y

# Debug (start light)
# CONFIG_ASSERT=y
# CONFIG_DEBUG=y
# CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_OPTIMIZATIONS=y
# CONFIG_DEBUG_THREAD_INFO=y
# CONFIG_THREAD_NAME=y

# Stacks
CONFIG_MAIN_STACK_SIZE=2048
CONFIG_ISR_STACK_SIZE=2048
CONFIG_IDLE_STACK_SIZE=512
CONFIG_STACK_SENTINEL=y
# Or: CONFIG_MPU_STACK_GUARD=y  (swap in after stack sizes are proven)

If you want a smoking gun

Enable the fault dump and read CFSR/BFAR to confirm a BusFault from log/ISR pressure, then re-enable pieces until it returns. (Standard Cortex-M33 fault doc here.) Arm Developer+1

One more practical check

Make sure the Seeed Xiao nRF54L15 board files you use match your NCS version; stale board defs against 3.1.x can cause oddities. Folks on the Seeed forum reported better luck moving from 3.0.x→3.1.1 with the Xiao. Seeed Studio Forum

Bottom line: flip to deferred logging, grow stacks, dial back debug flags, and try 3.1.1. That combo should stop the bus faults on the Xiao 54L15.

HTH
GL :slight_smile: PJ :v: