Zigbee weather station sample never boots on Thingy:53 (no LED activity at all) — NCS v2.9.0, macOS, isolated to Zigbee subsystem itself

[Gabor Bohm]

Setup:
- Board: Thingy:53
- Host: Mac Mini M4, 16GB, macOS Tahoe 26.6
- nRF Connect for Desktop v5.3.2, Programmer v4.8.0
- NCS v2.9.0, installed via Toolchain Manager (freshly reinstalled once during
troubleshooting — no change in behavior)
- Flashing: USB DFU via Programmer, dfu_application.zip built with
`west build -b thingy53/nrf5340/cpuapp --sysbuild`. DFU consistently
reports "Completed successfully" (~180s, including the expected net-core
wait).

Symptom:
The completely unmodified, official `nrf/applications/zigbee_weather_station`
sample builds and flashes without error, but the device shows ZERO visible
activity afterward — no LED blink/pulse, no CDC-ACM console output, ever
(left running untouched for 35+ minutes on one test, in case this was the
"~20 minute delayed join" behavior reported by other users in
devzone.nordicsemi.com/.../thingy-53-weather-station-demo-doesn-t-work
— it is not; there is no activity at all, not even a delayed one).

Isolation steps taken (with the help of an AI assistant, so please excuse
the thoroughness — we wanted to rule out our own code before reporting):
1. zephyr/samples/basic/blinky builds, flashes, and blinks correctly on the
same physical device via the same DFU process — rules out flashing
chain / hardware / USB DFU issues.
2. A minimal custom app (raw GPIO toggle loop, CONFIG_GPIO=y only, no
overlay) blinks correctly.
3. Adding the sysbuild netcore IPC radio image (NRF_DEFAULT_IPC_RADIO,
NETCORE_IPC_RADIO_IEEE802154 — same net-core image the Zigbee sample
uses) to that minimal app, WITHOUT any Zigbee API usage on the app core,
still blinks correctly — rules out the net-core radio image itself
failing to boot.
4. Adding just `CONFIG_ZIGBEE=y` + the mandatory
`CONFIG_ZIGBEE_USE_SOFTWARE_AES=y` (required or the build fails with
"No crypto suite for Zigbee stack has been selected") to that same
minimal app — again with ZERO Zigbee API calls anywhere in application
code, just a `zboss_signal_handler()` stub to satisfy the linker and an
unconditional `while(1) { gpio_toggle; k_msleep(300); }` loop — is
enough to make the LED never light at all. This app should be
completely independent of any Zigbee network activity, so this doesn't
look like a network-steering delay.
5. Our own extended application (adds BME688/BH1749/BMI270/BMM150/fuel
gauge/PWM/etc. on top of the weather_station pattern) shows the
identical symptom, and we were able to eliminate every one of those
additions individually (all disabled one at a time, all confirmed
innocent) before landing back on step 4 above.

This strongly suggests something in the Zigbee/ZBOSS subsystem's own
pre-main() or very-early initialization hangs indefinitely in this specific
environment (Apple Silicon Mac, this exact toolchain version, this exact
Thingy:53 unit), independent of application code.

Questions:
- Is this a known issue with NCS v2.9.0 + Thingy:53, particularly on
Apple Silicon Macs? The linked thread has at least one other Mac user
(M2 MacBook Air) with the identical symptom.
- Could this be a net-core radio firmware / IPC handshake issue that
manifests as a hang on the app core specifically when real ZBOSS
init (not just an idle netcore image) is involved?
- Any recommended next diagnostic step short of acquiring a J-Link/RTT
setup? Happy to provide full build logs, .config, or try specific
nRF Util / nrfjprog commands if that helps narrow it down.

Thingy:53 hardware revision label (if relevant): v1.1.0

[Gabor Bohm]

UPDATE: Further isolated this. Built and tested completely independent samples on the same hardware: - nrf/samples/bluetooth/peripheral_lbs (BLE, net core radio via different path) -> WORKS PERFECTLY, advertises and connects fine. - nrf/samples/openthread/cli (Thread, NOT Zigbee/ZBOSS at all, but same IEEE 802.15.4 radio + net core IPC serialization as Zigbee) -> IDENTICAL failure, zero activity, no console. - Both the R22 (bundled) and R23 (ncs-zigbee add-on) Zigbee stacks -> same failure. This strongly suggests the common factor is the IEEE 802.15.4 radio path / net core IPC serialization specifically, not Zigbee or ZBOSS, since OpenThread shares that same radio path but not the ZBOSS stack. Since BLE (different radio mode on the same physical radio) works fine, this could point to either a toolchain/driver issue specific to 802.15.4 mode, or a hardware/RF issue specific to this Thingy:53 unit's 802.15.4 path. Could this be a hardware/RF calibration issue? Is there a way to test the 802.15.4 radio's basic RF functionality (TX/RX) independent of any protocol stack, ideally without needing a second device?

[Maria Gilje]

Hello, 

Thank you for the report and for sharing your additional findings. We will need some time to look into this, but we are on it. If you continue investigating on your end as well we appreciate you sharing your progress. 

Best regards,

Maria

[Maria Gilje]

Hello, 

Regarding this: 

Gabor Bohm said:

Is there a way to test the 802.15.4 radio's basic RF functionality (TX/RX) independent of any protocol stack, ideally without needing a second device?

We have a short range radio test, documentation found here: https://nrfconnectdocs.nordicsemi.com/ncs/3.4.0/nrf/samples/peripheral/radio_test/README.html 

It has the option of using the RSSI Viewer app instead of another board. 

Best regards,

Maria

[Gabor Bohm]

Thank you for the suggestion. Unfortunately I don't have access to any other Nordic hardware (no second DK, dongle, or Thingy:53) to act as the RSSI Viewer's receiving device, so I'm not able to run that specific test. To summarize where this stands, since I think it's now a fairly clear pattern: I've tested three independent stacks that all use the IEEE 802.15.4 radio via the network core (Zigbee R22 bundled with NCS v2.9.0, Zigbee R23 via the ncs-zigbee add-on on NCS v3.4.0, and OpenThread CLI on NCS v2.9.0) — all three show *zero* activity whatsoever (no LED, no console, no network activity), even when isolated down to builds with no application-level radio API calls at all. In contrast, Bluetooth LE (nrf/samples/bluetooth/peripheral_lbs, also net-core radio) works perfectly — advertises and connects without issue. This pattern (every 802.15.4-based stack failing identically and completely, while BLE on the same chip/net-core works fine) is what makes me suspect this may be a hardware-level RF issue specific to the 802.15.4 radio path on this particular Thingy:53 unit, rather than a software/configuration problem — but I don't have the equipment (spectrum analyzer, second Nordic device) to confirm that myself. Given the above, would you agree this points toward a hardware fault? If so, could you advise on next steps — is this something that would qualify for a replacement unit (RMA), or is there another single-device-only diagnostic you could suggest?