Matter CASE resumption delayed 10+ minutes on nRF52840 due to BLE-first serial fabric fallback

Hi everyone,

I'm developing a matter generic switch and I’ve run into a puzzling behavior when commissioning an nRF52840 DK with Apple Home via an Apple TV Thread border router. After the switch reboots, it takes over ten minutes before the device finally becomes responsive again. By contrast, a similar Silicon Labs EFR32MG24 demo re-establishes secure channels in under a minute.  I got ChatGPT to compare the serial output of the EFR32MG24 and NRF52840 and here is the summary of what it thinks the issue is:

1. Two Fabrics in Apple Home Commissioning

When you commission with Apple HomeKit (Matter), you actually end up with two fabrics on your accessory:

  1. iOS Fabric (Fabric 0)

    • Established via Matter-over-BLE (CHIPoBLE) when your iPhone pairs and commissions the device.

    • Allows your phone to issue commands, OTA updates, diagnostics, etc., over BLE.

  2. Apple TV Fabric (Fabric 1)

    • Established via Thread when the Apple TV (or HomePod mini) acts as a Thread border router.

    • Provides full home-wide connectivity and lets the TV/hub control the device over the mesh.

Each fabric gets its own CASE session keys and ACLs, so your accessory must securely handshake with both controllers.


2. What the nRF52840 Demo Does (Wrong)

On reboot, the nRF52840 sample app:

  1. Disables BLE advertising immediately (assumes “production” Thread-only mode once commissioned).

  2. Calls Resuming 2 subscriptions in 0 seconds:

    • First it tries the iOS/BLE fabric → fails to connect (no BLE adv!) → times out with error 32.

    • Only after exhausting the BLE back-off (minutes!) does it try the Thread fabric → succeeds.

This serial fallback (BLE → fail → Thread) blocks your accessory for the entire BLE timeout before Thread CASE can even begin.


3. How the EFR32MG24 Demo Does It (Right)

The Silicon Labs demo on the same network:

  • Keeps BLE advertising enabled for a window on boot, and immediately advertises over Thread once SRP is ready.

  • This effectively rings both iOS (BLE) and Apple TV (Thread) controllers in parallel, so whichever controller responds first wins the race.

  • As a result, CASE Sigma1 arrives in seconds, not minutes.

ChatGPT suggests turning on bluetooth extended advertising to ensure bluetooth is enabled to advertise to fabric 0 (iOS) but those settings are enabled by default in the matter template project. 

Any suggestions on what might fix this?

Related