please help with recovery

[gleba]

after flashing to ncp-uart-sw_7.1.1.0_115200.gbl I return to ncp-uart-sw_v6.10.3_115200.gbl and get this error

python3 Elelabs_EzspFwUtility.py flash -f ncp-uart-sw_v6.10.3_115200.gbl -p /dev/tty.usbserial-1140 
2022/09/14 19:05:44 Elelabs_EzspFwUtility:   EZSP adapter in bootloader mode detected:
2022/09/14 19:05:44 Elelabs_EzspFwUtility:   [ASSERT:D:/SiliconLabs/SimplicityStudio/v5/developer/sdks/gecko_sdk_suite/v3.2/platform/base/hal/micro/cortexm3/efm32/token.c:211]
2022/09/14 19:05:44 Elelabs_EzspFwUtility:   Allready in bootloader mode. No need to restart
2022/09/14 19:05:45 Elelabs_EzspFwUtility:   Successfully restarted into X-MODEM mode! Starting upload of the new firmware... DO NOT INTERRUPT(!)
2022/09/14 19:05:55 Elelabs_EzspFwUtility:   Failed to restart into bootloader mode. Please see users guide.
--------------------------------------------------------------------------------------------------------------------------------------------

can this be fixed programmatically or just recovery?

how recovery is hard?

[TheJulianJES]

FYI, I also have the same issue. Another user also reported this on the HA forums: https://community.home-assistant.io/t/itead-s-sonoff-zigbee-3-0-usb-dongle-plus-v2-model-zbdongle-e-based-on-silicon-labs-efr32mg21-20dbm-radio-mcu-now-sold-for-19-99/442695/64

[TheJulianJES]

I'm wondering if it's somehow possible that some settings are leftover from 7.0.x/7.1.x that 6.10.x isn't compatible with. Is it possible to reset the NVRAM?

[MattWestb]

In silabs docks i have not finding any way doing that only deleting all keys in the key token storage with EZSP commands. So only way is doing one chip erase and flashing bottloader and NCP app thru SWD for getting it 100% clean.

For my its looks like one problem with Elelabs flash utility not reading the state of the bootloader. Can trying other methods doing the upgrade with ncp.py or bellows for betting in bootloader and one terminal with x-modem for file transfer also HA team have one for SkyConnect and the new boxes that i have not testing.

Also is elelabs reading the version of the bootloader ? if yes then its not working with new bootloaders that is having higher version and getting problems.

[TheJulianJES]

Tried some other methods to downgrade back to 6.10.x but none seem to work so far. I can upgrade back to 7.0.x or 7.1.x just fine when in the bootloader (although there's an issue where bellows tries to set the supported networks to 1. The firmware is compiled with 2 and 7.x seems to disallow lowering the limit for some reason (likely a bug). This can be worked around with, but the memory reserved for two supported networks is obviously bigger than one.

I also don't have access to the EmberZNet SDK because I don't have a DevKit. I should probably get one at some point lol

[MattWestb]

I think the supported network is not one bug then its hard coded in the firmware it cant being changed (its have doubling most of the code in the firmware also the key storage must being different for 2 networks). The interesting if that is the reason way one firmware with 1 network have one other data structure of the NVR / key token storage and its not liking running with the wrong storage type.

Do you have more logs then i cant getting the feeling what is happening ?

You only need one J-Link probe (EDU or good working CE clone) and using Silabs commander for doing flashing and dumping of the chip (MG21 its one must) and then you can erasing the flash pages used for the NVR and the NCP is recreating new empty ones then its doing the next boot.

[MattWestb]

I think its not helping but one other flasher / down loader that works little different that can being worth testing https://github.com/agners/silabs-flasher/ and can getting little more info from the bootloader (i have not testing it only seen the screen shuts).

Edit: Instruction how to (ab)use HA core for flashing https://github.com/NabuCasa/silabs-firmware#silicon-labs-firmware-for-yellow-and-skyconnect.

[TheJulianJES]

Do you have more logs then i cant getting the feeling what is happening ?

I don't really have any logs unfortunately. The only thing I can see is that this is sent via serial about every second when on the 6.10.3 firmware from this repo: ASSERT:D:/SiliconLabs/SimplicityStudio/v5/developer/sdks/gecko_sdk_suite/v3.2/platform/base/hal/micro/cortexm3/efm32/token.c:211]. When I'm installing the official 6.10.3 ITEAD firmware, the serial output stays empty when it's started.

Before I initially installed 7.x firmware, I confirmed that both the ITEAD 6.10.3 and the 6.10.3 firmware from this repo worked on the stick.

Also, the bootloader always works and doesn't have any issues:

Sonoff v1.0.1

Gecko Bootloader v1.12.00
1. upload gbl
2. run
3. ebl info
BL >

The SkyConnect bootloader version is "already" v2.00.02.

I think its not helping but one other flasher / down loader that works little different that can being worth testing https://github.com/agners/silabs-flasher/ and can getting little more info from the bootloader (i have not testing it only seen the screen shuts).

I've used both agners silabs-flasher and elelabs-zigbee-ezsp-utility for this and while both work great, 6.10.3 still doesn't boot (I guess it's in a bootloop).

[MattWestb]

I think = not knowing and my feeling is problems with the token storage for the keys and its coming from that one firmware is having 2 network configured.

So in the end its one isolated ITEAD problem and not one general MG21 problem.

Ops i was looking what is in the file with assert and the line before is this:

  // If the NVM3 cache overflows it is too small to index all live and deleted NVM3 objects

= cache.overflow in line 211. So without posting the restricted Silabs code we is knowing its one token storage problem and its its only in ITEAD "firmwared" devices !!!

PS: I have not time hacking my SkyConnect and testing different firmware then the fabric shipped one but like testing Zigbee NCP with OTR NCP version.

[MattWestb]

The 7.X have nearly the same code here only the last (our) cache.overflow is not in the code but you can see what is all of the token storage that is doing the NCP not starting. https://github.com/SiliconLabs/gecko_sdk/blob/310814a9016b60a8012d50c62cc168a783ac102b/platform/service/legacy_hal/src/token_legacy.c#L48 Its the not closed code in the Silabs git so not danger posting it.

My new theory is that the NVM3 is configured with different size / parameters in the firmwares and the 6.10 is getting problems if the NVR is made with the other parameters.

Edit: The problem is only being then flashing with bootloader and not then erasing the flash with SWD and flashing with Silabs commander or other chip flasher !!

[MattWestb]

@xsp1989 Do you have somthing to do with the new firmware "collection" of knowing some that can taking one look on this problem that looks being different setting of the NVM3 is making the 6.10 EZSP NCP not starting if have installing some higher version of the firmware before = cant flashing all firmware on the device if one 7.x have being running in the chip.

Thanks in advance.

Mattias W

Edit: One way is making all versions is using the same NVM3 setting if its possible but i can being changes made in GSDK that making it not possible => bug report to Silabs.

[FranzSchi]

Hi, I also trapped into this issue I could not even bring it back to Version 7.1.1 after trying to flash back to 6.10.3 any ideas what can I do? is here any Hardware button that can be pressed to reset?

frsc@raspi:/opt/elelabs-zigbee-ezsp-utility-master $ ./Elelabs_EzspFwUtility.py flash  -p /dev/ttyUSB0 -f ncp-uart-sw_7.1.1.0_115200.gbl
2022/10/05 15:29:57 Elelabs_EzspFwUtility:   EZSP adapter in bootloader mode detected:
2022/10/05 15:29:57 Elelabs_EzspFwUtility:   [ASSERT:D:/SiliconLabs/SimplicityStudio/v5/developer/sdks/gecko_sdk_suite/v3.2/platform/base/hal/micro/cortexm3/efm32/token.c:211]
2022/10/05 15:29:57 Elelabs_EzspFwUtility:   Allready in bootloader mode. No need to restart
2022/10/05 15:29:58 Elelabs_EzspFwUtility:   Successfully restarted into X-MODEM mode! Starting upload of the new firmware... DO NOT INTERRUPT(!)
2022/10/05 15:30:08 Elelabs_EzspFwUtility:   Failed to restart into bootloader mode. Please see users guide.

[TheJulianJES]

You can bring it back to 7.0.x or 7.1.x just fine. Open up the case on either side (two screws) and hold down the BSL (should be the one on the inner side IIRC), then plug it in while holding down that button. The dongle will go into bootloader mode and you can flash 7.x firmware again. (Instead of replugging, you can also just hold the BSL button and briefly press the reset button, then let go of both buttons)

[FranzSchi]

Hi,

@TheJulianJES , Thanks alot it worked. Hold the upper button and plugged in. Then Immediately I've startred to flash (taking to long does not work)

THX /Franz

[xsp1989]

@MattWestb @gleba @TheJulianJES @FranzSchi I built a firmware with the latest version of GSDK (4.1.2), with default parameters, and can fall back to 6.7.9. After the last version of the firmware (7.1.1.0) was rolled back, the old firmware would trigger an overflow error, causing the code to enter an assert. Those who have upgraded the latest version of the firmware temporarily use version 7.1.1.0. If the rollback fails, you can manually enter the bootloader and then upgrade. A firmware will be released later to fix this bug.

[FranzSchi]

Hi @xsp1989 ,

first of all thank you soooo much for your reply! I've just tried to revert back to 6.7.9. After upgrading to 7.1.1. It seems the device will not come back after flashing (reboot and then nothing happens). See log below. Did i missunderstood the procedure planned? => Upgrade to 7.1.1 and then downgrade to 6.7.9?

frsc@raspi:/opt/elelabs-zigbee-ezsp-utility-master $ python3 Elelabs_EzspFwUtility.py flash -p /dev/ttyUSB0 -f ncp-uart-sw_7.1.1.0_115200.gbl
2022/10/13 09:53:46 Elelabs_EzspFwUtility:   EZSP adapter in bootloader mode detected:
2022/10/13 09:53:46 Elelabs_EzspFwUtility:   Gecko Bootloader v1.9.2
2022/10/13 09:53:46 Elelabs_EzspFwUtility:   Allready in bootloader mode. No need to restart
2022/10/13 09:53:47 Elelabs_EzspFwUtility:   Successfully restarted into X-MODEM mode! Starting upload of the new firmware... DO NOT INTERRUPT(!)
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
...
2022/10/13 09:54:29 Elelabs_EzspFwUtility:   Firmware upload complete
2022/10/13 09:54:29 Elelabs_EzspFwUtility:   Rebooting NCP...
2022/10/13 09:54:36 Elelabs_EzspFwUtility:   Generic Zigbee EZSP adapter detected:
2022/10/13 09:54:36 Elelabs_EzspFwUtility:   Firmware: 7.1.1-17
2022/10/13 09:54:36 Elelabs_EzspFwUtility:   EZSP v9
frsc@raspi:/opt/elelabs-zigbee-ezsp-utility-master $ python3 Elelabs_EzspFwUtility.py flash -p /dev/ttyUSB0 -f ncp-uart-sw_679_115200.gbl
2022/10/13 09:55:07 Elelabs_EzspFwUtility:   Generic Zigbee EZSP adapter detected:
2022/10/13 09:55:07 Elelabs_EzspFwUtility:   Firmware: 7.1.1-17
2022/10/13 09:55:07 Elelabs_EzspFwUtility:   EZSP v9
2022/10/13 09:55:07 Elelabs_EzspFwUtility:   Launch in bootloader mode
2022/10/13 09:55:17 Elelabs_EzspFwUtility:   EZSP adapter in bootloader mode detected:
2022/10/13 09:55:17 Elelabs_EzspFwUtility:   Gecko Bootloader v1.9.2
2022/10/13 09:55:18 Elelabs_EzspFwUtility:   Successfully restarted into X-MODEM mode! Starting upload of the new firmware... DO NOT INTERRUPT(!)
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
....
2022/10/13 09:55:50 Elelabs_EzspFwUtility:   Firmware upload complete
2022/10/13 09:55:50 Elelabs_EzspFwUtility:   Rebooting NCP...
2022/10/13 09:56:05 Elelabs_EzspFwUtility:   Couldn't communicate with the adapter in Zigbee (EZSP) mode, Thread (Spinel) mode or bootloader mode

[xsp1989]

Only 7.1.1.0 can be used for now, and a firmware may be released in the future specifically for erasing the NVM area.

[Arc86]

I was able to run7.0.2.0 after using 7.1.1.0 but that is as low as it goes for now. I am really looking forward to that firmware that can erase the NVM aera. @xsp1989 is it something you are planning to create? Or do we need to wait until SilicionLabs has this functionality released?

[MattWestb]

@xsp1989 Is it possible making one GBL that is writing one empty block from the end of the normal app (firmware) to the end of the flash (there is the NVM3 automatically allocated) so the bootloader is deleting the NVM3 allocated and the app is making one new on the next boot of the chip ?

Direct manipulations of the flash is not possible with GBL files only with S37 and HEX that cant being flashed with bootloader or with Silabs commander and SWD.

Likely its need first flashing the 6.10 and then the fix for deleting the all the rest of the flash. Perhaps is possible putting both files with Silabs commander in to one GBL file (combining files).

Also in Silabs commander read the flash map after have erasing the chip and flashing bootloader and app you is getting the pages being allocated for app and also the NMV3.

Example of flash map after flashing one NCP and the chip have rebooting and allocating the NVM3 in one Silabs Light module: So one "erase NVM3" for this chip shall being 0x00050000 - 0x000fffff (i think the flash size is not the same as yours) filed with 0x0 (or is it 0x1 ? dump the flash and look and you is knowing what is right) all the way and adding it on one GBL so user can flashing it from the bootloader.

[MattWestb]

@TheJulianJES Still no J-Link on your desktop ?? Im interesting of one flash map from one if you is knowing some advanced user that can doing it. Best with original 6.10 and not upgraded for see how its looks untouched.

[xsp1989]

@MattWestb The reason why it cannot be downgraded has been analyzed. The 7.1.1.0 firmware uses more NV tokens, the cache of the previous firmware is not enough, and a transfer overflow occurs during initialization. There are currently two solutions for repair. The first is to recompile the previous firmware and increase the cache. The second is to erase the NV area in some way, may I ask, do you have any comments?

[xsp1989]

@MattWestb NV can use a dedicated firmware call API to erase the FLASH, and maybe a special gbl file to overwrite the NV area (not tested). I also found that there is an API to erase the custom MAC, do I need to add this function?

[MattWestb]

With Silabs commander is possible dont all like deleting / changing manufacture toke like the custom IEEE or manufacture and broad ID token saved in user data but its not possible doing it in one GBL file (at least i have not getting it working).

As standard NCP firmware is no use implanting more / new not existing function and if one user is burning one new IEEE is one time thing and cant being redone as long not erasing the chip with SWD.

Can you making one "flash map" for one "factory new" 6.10 flashed chip ? I can trying making one GBL that is erasing the rest of the flash if i getting the right (end)addresses the app is using and the end of the real flash (very likely one very large GBL file). Alternative one end address for the APP being flashed from your flash program. Also the absolute en of the main flash then i only have MG21 with 1M flash and cant testing it on them.

I think the permanent solution is patching the 6.10 so the token cash is not panic on start but i think trying one "GBL NVM erase" is one good temporary solution for user getting there device working OK.

[xsp1989]

flash map: 0-0x3fff: bootloader 0x000b6000-0x000bcfff: NVM

Areas other than the bootloader can be erased or overwritten. Warning: This flash map is only for unsigned Dongle, ZBB and ZB-GW03 have different flash layouts

By the way, the custom MAC address is written in the extra 1k security area on BANK1, which must be erased in the code through a special API, and cannot be erased through jlink

[MattWestb]

What is the end of the app then being flashed (start is 0x4000 after the bootloader last flash page ends at 0x3fff) ? I think some versions of chips is allocating the NVM3 is different flash pages after being retested so i like getting all from end of the app to end of the main flash. Erasing from 0x4000 to end of the main flash we are losing the app and is very likely landing in the bootloader then rebooting the chip. Can being OK for getting real clean but not good for normal users then need flashing the 6.10 one more time.

BANK0 = main flash for bootloader and app. BANK1 = user data and i think its more protected in MG2 devices that MG1 chips i have working with. Its normally having user data tokens and the over ride IEEE token (and manufacture and and board ID if being set from the factory (= not done in the first gen ZBGW) but can being harder protected in your MG21 chip (not tested on MG21).

The chip original IEEE is burned in the chip hardware conf aria and cant being manipulated after it have left the factory.

[xsp1989]

I've updated the description of the map, I tried to build a hex file that only contains 0xff, but can't convert to gbl via command. Some checksums may be included in a valid hex file.

[MattWestb]

Make one bin file (no CRC is plane data) with the right size and adding / converting it to one GBL with the load address (0x4000 + size of your flashed 6.10 app).

[MattWestb]

I think this is the same chip you have: Perhaps different rev but the same as tuya is using in there MG21 module. So main flash is from the bootloader 0x4000 to end at 0xC000. Best is getting the first flash page after the app so cant destroying the main firmware and to the end of the flash.

[MattWestb]

By the way from commander \tokens\Readme.txt:

USERDATA

 The data in the user data page is NOT erased via a mass erase
 ("commander.exe flash --masserase", "commander.exe masserase" or when
 disabling debug lock). It can, however, be erased by a specific page
 erase.
 Located at address 0x0FE00000 with size 2 kB on EFR32 devices.

That is also the storage for the token for the onetime IEEEE / MAC that cant being erased if not erasing the user data flash pages manual with SWD.

[xsp1989]

@MattWestb @gleba I updated a gbl file specially used to initialize NVM3, and it can be recovered by updating the file under the bootloader.

https://github.com/xsp1989/zigbeeFirmware/blob/master/firmware/Zigbee3.0_Dongle-NoSigned/EZSP/nvm3_initfile.gbl

[Arc86]

I can confirm this is working! With ExtraPutty Flashed the nvm3_initfile.gbl first. Afterwards while still in the bootloader flashed the original ncp-uart-sw_EZNet6.10.3_V1.0.1.gbl.

And upon checking with elelabs I get this output: 2022/10/15 09:46:49 Elelabs_EzspFwUtility: Generic Zigbee EZSP adapter detected: 2022/10/15 09:46:49 Elelabs_EzspFwUtility: Firmware: 6.10.3-41 2022/10/15 09:46:49 Elelabs_EzspFwUtility: EZSP v8

Thanks a million @xsp1989 @MattWestb

[MattWestb]

Great done @Arc86 one very brave user !!!

I think its not needed flashing the 6.10 one more time but its good to knowing that is working well !!

Great thanks to @xsp1989 for the fast fix and hope hi is getting one fixed EZSP 6.10 that not need the work around fix and the user dont getting problem in the future.

[FranzSchi]

THX @Arc86 , @MattWestb , @xsp1989

today I've tried to downgrade my ITLEAD Dongle with the elelabs tool, but had no success. Is there somehwere a description how to do this procedure with "extraputty"?

Thx /Franz

frsc@raspi:/opt/elelabs-zigbee-ezsp-utility-master $ python3 Elelabs_EzspFwUtility.py flash -p /dev/ttyUSB0 -f nvm3_initfile.gbl
2022/10/15 10:49:33 Elelabs_EzspFwUtility:   EZSP adapter in bootloader mode detected:
2022/10/15 10:49:33 Elelabs_EzspFwUtility:   Gecko Bootloader v1.9.2
2022/10/15 10:49:33 Elelabs_EzspFwUtility:   Allready in bootloader mode. No need to restart
2022/10/15 10:49:34 Elelabs_EzspFwUtility:   Successfully restarted into X-MODEM mode! Starting upload of the new firmware... DO NOT INTERRUPT(!)
send error: expected ACK; got b'\x18' for block 1
send error: expected ACK; got b'\x18' for block 1
send error: expected ACK; got b'\x18' for block 1
send error: expected ACK; got b'\r' for block 1
send error: expected ACK; got b'\n' for block 1
send error: expected ACK; got b'S' for block 1
send error: expected ACK; got b'e' for block 1
send error: expected ACK; got b'r' for block 1
send error: expected ACK; got b'i' for block 1
send error: expected ACK; got b'a' for block 1
send error: expected ACK; got b'l' for block 1
send error: expected ACK; got b' ' for block 1
send error: expected ACK; got b'u' for block 1
send error: expected ACK; got b'p' for block 1
send error: expected ACK; got b'l' for block 1
send error: expected ACK; got b'o' for block 1
send error: expected ACK; got b'a' for block 1
send error: NAK received 17 times, aborting.

2022/10/15 10:49:41 Elelabs_EzspFwUtility:   Firmware upload failed. Please try a correct firmware image or restart in normal mode.
frsc@raspi:/opt/elelabs-zigbee-ezsp-utility-master $ python3 Elelabs_EzspFwUtility.py flash -p /dev/ttyUSB0 -f ncp-uart-sw_v6.10.3_115200.gbl
2022/10/15 10:49:52 Elelabs_EzspFwUtility:   EZSP adapter in bootloader mode detected:
2022/10/15 10:49:52 Elelabs_EzspFwUtility:   Gecko Bootloader v1.9.2
2022/10/15 10:49:52 Elelabs_EzspFwUtility:   Allready in bootloader mode. No need to restart
2022/10/15 10:49:53 Elelabs_EzspFwUtility:   Successfully restarted into X-MODEM mode! Starting upload of the new firmware... DO NOT INTERRUPT(!)
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....

2022/10/15 10:50:30 Elelabs_EzspFwUtility:   Firmware upload complete
2022/10/15 10:50:30 Elelabs_EzspFwUtility:   Rebooting NCP...
2022/10/15 10:50:43 Elelabs_EzspFwUtility:   EZSP adapter in bootloader mode detected:
2022/10/15 10:50:43 Elelabs_EzspFwUtility:   [ASSERT:D:/SiliconLabs/SimplicityStudio/v5/developer/sdks/gecko_sdk_suite/v3.2/platform/base/hal/micro/cortexm3/efm32/token.c:211]
frsc@raspi:/opt/elelabs-zigbee-ezsp-utility-master $

[FranzSchi]

What i also tried was using extraputty. when I open "Serial COM4 115200".

But I have the problem that i don't know the order. If I select then "File upload Xmodem send" it cannot upload because its not in the bootloader mode. If i put it in bootloader mode i cannot select the file to upload anymore.

Looks like in the end having a modal upload dialog without being able to press "1"

[MattWestb]

Then getting the C is the bootloader waiting for the upload staring. Click "file Transfer" and X-modem send file and select the GBL file you like uploading.

If not have pressing 1 and getting the C the bootloader is not ready for receiving the file and you is getting time out.

[FranzSchi]

Thanks @MattWestb ,

I've tried it but did not succeed, see the result below. If I press upload it shows immediately aborting.

[MattWestb]

No flow control for bootloader mode.

[FranzSchi]

Seems to have no bigger effect:

I've also uploaded 7.1.1 with extraputty and this worked properly.

This is confusing. /Franz

[MattWestb]

Then 7.1.1 is working try downloading the fix GBL one more time then somthing is not OK with it and shall being possible flashing from the bootloader.

[FranzSchi]

So, now I'm one step closer I've flashed -> ncp-uart-sw_7.0.2.0_115200.gbl with ExtraPutty -> nvm3_initfile.gbl with ExtraPutty (was working after flashing before 7.0.2) -> ncp-uart-sw_v6.10.3_115200.gbl with ExtraPutty

AND Finally -> ncp-uart-sw_v6.10.3_115200.gbl with Elelabs_EzspFwUtility

2022/10/15 13:24:39 Elelabs_EzspFwUtility:   Generic Zigbee EZSP adapter detected:
2022/10/15 13:24:39 Elelabs_EzspFwUtility:   Firmware: 6.10.3-41
2022/10/15 13:24:39 Elelabs_EzspFwUtility:   EZSP v8
2022/10/15 13:24:39 Elelabs_EzspFwUtility:   Launch in bootloader mode
2022/10/15 13:24:48 Elelabs_EzspFwUtility:   EZSP adapter in bootloader mode detected:
2022/10/15 13:24:48 Elelabs_EzspFwUtility:   Gecko Bootloader v1.9.2
2022/10/15 13:24:49 Elelabs_EzspFwUtility:   Successfully restarted into X-MODEM mode! Starting upload of the new firmware... DO NOT INTERRUPT(!)
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....
.....

2022/10/15 13:25:26 Elelabs_EzspFwUtility:   Firmware upload complete
2022/10/15 13:25:26 Elelabs_EzspFwUtility:   Rebooting NCP...
2022/10/15 13:25:34 Elelabs_EzspFwUtility:   Generic Zigbee EZSP adapter detected:
2022/10/15 13:25:34 Elelabs_EzspFwUtility:   Firmware: 6.10.3-41
2022/10/15 13:25:34 Elelabs_EzspFwUtility:   EZSP v8

But now I get this error Message in Openhab. :-(

2022-10-15 14:36:23.831 [DEBUG] [nding.zigbee.serial.ZigBeeSerialPort] - Connecting to serial port [/dev/ttyACM99] at 115200 baud, flow control FLOWCONTROL_OUT_XONOFF.

2022-10-15 14:36:23.859 [DEBUG] [nding.zigbee.serial.ZigBeeSerialPort] - Serial port [/dev/ttyACM99] is initialized.

==> /var/log/openhab/events.log <==

2022-10-15 14:36:28.026 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:coordinator_ember:62ec522f14' changed from OFFLINE (COMMUNICATION_ERROR) to OFFLINE: Failed to startup ZigBee transport layer

2022-10-15 14:36:28.032 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:coordinator_ember:62ec522f14' changed from OFFLINE: Failed to startup ZigBee transport layer to OFFLINE (COMMUNICATION_ERROR)

the ncpstate shows quite empty values

openhab> zigbee ncpstate
Ember NCP state     : EMBER_NO_NETWORK
Local Node Type     : UNKNOWN
IEEE Address        : 04DD15FFFEBB3FFF
Custom IEEE Address : FFFFFFFFFFFFFFFF
NWK Address         : FFFE
Network PAN Id      : FFFF
Network EPAN Id     : 0000000000000000
Radio Channel       : 0
Network Manager Id  : FFFF
Radio TX Power      : -1
Join Method         : EMBER_USE_MAC_ASSOCIATION
Board Name          :
Manufacturer Name   :
Stack Version       : 6.10.3.0
Custom Version      :

[Arc86]

Ah yes, I was actually running ncp-uart-sw_7.0.2.0_115200.gbl before applying the fix. I downgraded from 7.11 a while back. Sorry I didn’t mention it. Could have saved you some hours.

I will check my dongle behavior in Home Assistant / ZHA. But preliminary checks didn’t find any issues. I did apply Iteads official 6.10 firmware though not the one from @xsp1989

[FranzSchi]

@Arc86 , where can I find the original firmware? This? https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/blob/master/Dongle-E/Router/Z3RouterUSBDonlge_EZNet6.10.3_V1.0.0.gbl

[Arc86]

this one actually the other one is the router firmware

https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/blob/master/Dongle-E/NCP/ncp-uart-sw_EZNet6.10.3_V1.0.1.gbl

[xsp1989]

The fix is as follows:

1. Downgrade to 6.10.3 or 6.7.9
2. Press and hold the BOOT button, then press RST again, then release BOOT to enter the bootloader
3. Upgrade nvm3_initfile.gbl

[FranzSchi]

After setting this and save it works in Openhab! Many THX to all!

[MattWestb]

Great @FranzSchi !! After flashing the fix GBL is all the network information erased in the chip and need to forming one new network or restoring one old backup if you system can doing it. So Ember NCP state : EMBER_NO_NETWORK = the fix is working and after forming you shall getting one network in your system.

Glad to see our user is getting there system up and running beside Z2M and ZHA :-)))

[RuSPanzer]

yours breathtaking, guys

you all rescued my dongle 🙏