Thingy 53 Weather station demo doesn't work

[kocouj1]

I have new Thingy 53. Default Edge Inpulse demo works without any problem. But I have problem with Weather Station demo.

First I tested Zigbee version. After flashing using nRF Programmer it doesn't do nothing. No LED action, can't connect to Zigbee coordinator (I have many Zigbee devices and newer had problem connecting them).

Next I tested Matter version. Thingy should flash blue LED after start but LED is always on - not flashing. So this does something but not works as described in documentation.

Is some problem on my side? Definitelly I'd like to use Zigbee version but currently device seems dead every time I flash it.

[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): 1.1.0