ZHA fails to create network after upgrading EFR32MG21 firmware to 8.0.2

[ErKeye]

Description
On a clean Home Assistant installation, when installing the ZHA integration for a Silicon Labs EFR32MG21 Zigbee module (firmware upgraded from 6.10.3 to 8.0.2), the setup process fails during network formation. Although the device is detected correctly, ZHA cannot complete the installation and reports an error when creating the new network.

Steps to Reproduce

1. Start from a fresh Home Assistant docker container.
2. Upgrade the EFR32MG21 module firmware from 6.10.3 to 8.0.2.
3. Restart Home Assistant and navigate to Settings → Devices & Services → Integrations.
4. Click Add Integration and select ZHA.
5. Choose EZSP device path (e.g. /dev/ttyUSB1) and proceed with the setup wizard.
6. At the network formation step, select Create a new network.
7. Observe that ZHA fails during the network formation step, logging a parsing error.

Expected Behavior
The ZHA integration should successfully initialize the network and allow pairing of Zigbee devices, as it did with firmware 6.10.3.

Actual Behavior
Network creation fails immediately when starts network formation, producing the following relevant log entries:

2025-05-28 10:46:05.671 DEBUG (MainThread) [zigpy.application] Forming a new network
2025-05-28 10:46:05.672 DEBUG (MainThread) [zigpy.backups] Restoring backup NetworkBackup(version=1, backup_time=2025-05-28 10:46:05.672114+00:00, network_info=…)
2025-05-28 10:46:05.704 DEBUG (MainThread) [bellows.ezsp.protocol] Sending command tokenFactoryReset: () {'excludeOutgoingFC': False, 'excludeBootCounter': False}
…
2025-05-28 10:46:05.848 WARNING (MainThread) [bellows.ezsp.protocol] Failed to parse frame getTokenData: b'0e000000'
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/site-packages/bellows/ezsp/protocol.py", line 173, in __call__
    result, data = rx_schema.deserialize(data)
  File "/usr/local/lib/python3.13/site-packages/zigpy/types/struct.py", line 319, in deserialize
    value, data = field_type.deserialize(data)
  File "/usr/local/lib/python3.13/site-packages/zigpy/types/basic.py", line 729, in deserialize
    raise ValueError("Data is too short")
ValueError: Data is too short
2025-05-28 10:46:05.937 WARNING (MainThread) [bellows.ezsp] Failed to parse frame, ignoring
2025-05-28 10:46:17.071 ERROR (MainThread) [aiohttp.server] Error handling request from 172.20.0.10

Environment

• Home Assistant version: 2025.05.3
• bellows version: 0.45.0
• zigpy version: 0.79.0
• Hardware: Silicon Labs EFR32MG21 SoC

Full Debug Log
I have attached the complete debug log file (bellows-full-debug.log), which contains all output from the moment Zigpy initializes through the point where the error occurs. This file is approximately 1 000 lines long and may help diagnose the issue in detail.

bellows_full-debug.log

[puddly]

What adapter and firmware are you using?

From what it looks like, your firmware is not compiled with all of the features that bellows expects to be present: getTokenData returns NOT_AVAILABLE, which likely means your firmware has NV3 tokens disabled.

[ErKeye]

The adapter is the Dusun DSGW-210, which uses an EFR32MG21 module, and I’m running firmware version 8.0.2 as provided by the manufacturer.

[puddly]

I would reach out to the manufacturer then, this is a product branded to work with Home Assistant so I would expect them to have tested it with ZHA. We work with other 8.x firmwares without issues.

If you're feeling industrious, you could try writing a manifest file for your chip and compile your own firmware for it using our firmware builder: https://github.com/NabuCasa/silabs-firmware-builder/blob/main/manifests/nabucasa/yellow_zigbee_ncp.yaml. Those have all of the expected features baked in.

[ErKeye]

I’m always up for experimenting, but I already have one DSGW-210 with its Zigbee module bricked and I don’t want to brick this one too. The whole compilation process is quite unfamiliar to me and I’m not sure which values I need to define in the manifest file—or whether the values already defined in the linked manifest would work for my device.

Since asking for detailed help with this might be off-topic here, do you know of any documentation or forum thread that explains the process step by step, so I can tackle it without working completely in the dark?

In any case, I’m waiting for a JTAG programmer to try to recover the bricked device. Once I have it, I’ll probably give it a shot, even if I’m flying blind.

I’d really love to get ZHA working with this device, so any pointers or resources would be hugely appreciated.

[pipiche38]

How did you Upgrade the EFR32MG21 module firmware from 6.10.3 to 8.0.2 ?
What procedure, tools ? and where did you get the firmware from ?

[ErKeye]

How did you Upgrade the EFR32MG21 module firmware from 6.10.3 to 8.0.2 ? What procedure, tools ? and where did you get the firmware from ?

As mentioned previously, I received the firmware directly from the manufacturer, and I flashed it using their official tool, AmberGwZ3.

[puddly]

@ErKeye You basically need to fill out just the device, TX and RX pin fields. Here's an example:

name: DSGW-210 Zigbee
device: EFR32MG1B232F256GM32  # Taken from the product datasheet
base_project: src/zigbee_ncp
filename: "{manifest_name}_{ezsp_version}_{fw_variant}"
sdk: "gecko_sdk:4.4.6"
toolchain: "12.2.1.20221205"

gbl:
  fw_type: zigbee_ncp
  ezsp_version: dynamic
  baudrate: 115200

c_defines:
  XNCP_MFG_MANUF_NAME: '"ErKeye"'
  XNCP_MFG_BOARD_NAME: '"DSGW-210"'
  XNCP_BUILD_STRING: template:"{now:%Y%m%d%H%M%S}"

  EMBER_APS_UNICAST_MESSAGE_COUNT: 32
  EMBER_BINDING_TABLE_SIZE: 32
  EMBER_BROADCAST_TABLE_SIZE: 64
  EMBER_KEY_TABLE_SIZE: 12
  EMBER_MAX_END_DEVICE_CHILDREN: 32
  EMBER_PACKET_BUFFER_COUNT: 255
  EMBER_SOURCE_ROUTE_TABLE_SIZE: 200

  EMBER_CHILD_TABLE_SIZE:
    type: c_flag
    value: 32

  SL_IOSTREAM_USART_VCOM_BAUDRATE: 115200
  SL_IOSTREAM_USART_VCOM_FLOW_CONTROL_TYPE: usartHwFlowControlNone

  SL_IOSTREAM_USART_VCOM_PERIPHERAL: USART0
  SL_IOSTREAM_USART_VCOM_PERIPHERAL_NO: 0

  # You will have to take apart the device to figure these out. This example config sends
  # serial data via A8 and receive via A7 but your device is different.
  SL_IOSTREAM_USART_VCOM_TX_PORT: gpioPortA
  SL_IOSTREAM_USART_VCOM_TX_PIN:  8
  SL_IOSTREAM_USART_VCOM_RX_PORT: gpioPortA
  SL_IOSTREAM_USART_VCOM_RX_PIN:  7

[ErKeye]

@puddly Thank you so much for your guidance and the example manifest!

I have one more question: what’s the recommended way to determine which pins the DSGW-210 uses for UART TX/RX?
Should I consult the manufacturer’s documentation for a pinout, open the device and inspect the PCB silkscreen, or is there another approach you’d suggest?

[puddly]

It's a little difficult to say, you just have to figure it out 😅. One way would be to see how the UART is set up on Linux, see what pins on the SOC are used for it, and then trace them back to the Zigbee module chip.

There's no standard set of pins for these modules unfortunately so every one is unique. It could even be printed on the silkscreen.