Problem with flashing sonoff-e with firmware ezsp 7.3.1.0

[mamrai1]

https://github.com/Koenkk/zigbee-herdsman/issues/319#issuecomment-1674295841

Also tried flashing nvm3 and then reflashing ezsp 7.3.1. 0 on sonoff zbdongle e but i can't probe the device

[darkxst]

Hi Mamrai1, Can you try again with the 7.3.1 firmware but add the --verbose flag to generate debug logs for universal-silabs-flasher. Do this for both the flash and probe. Once you have these attach the logs to this issue as files (they will be really long otherwise!)

[mamrai1]

/ probeafterreflashing7110.log probefail.log flash.log probe7110.log

[mamrai1]

I downloadwd the firmware using wget.

[wastez]

As already mentioned before i had the same problem with 7.3.1 but i'm sure you still know it.

[mamrai1]

As already mentioned before i had the same problem with 7.3.1 but i'm sure you still know it.

Did you experience the problem with 7.3.0 and 7.2.3?

[darkxst]

flash.log

This log is missing debug logs and is incomplete, can you try again.

Did you experience the problem with 7.3.0 and 7.2.3?

No I have never experienced this problem with any of the builds on my repo.

It probably wont help, but have you tried with the web flasher? same issues? https://darkxst.github.io/silabs-firmware-builder/

[wastez]

As we already tried it with different flasher (elelabs and silabs) I can’t imagine that the webflasher will help.

To be fair I have to say I don’t install other build from this repo. I installed the latest versions (it was 7.2.2) from xsp1989 and I had other problems with z2m. But like here that the firmware seems to be destroyed after flashing i never had before.

[darkxst]

As we already tried it with different flasher (elelabs and silabs) I can’t imagine that the webflasher will help.

The webflasher uses universal-silabs-flasher under the hood, however it also runs completely isolated from the python environment on your machine, just in case something in there is causing the issues.

I have not been able to reproduce this issue myself, and I have flashed dozens of times the various ezsp zbdongle-e builds from 7.2.x and 7.3.x. So unless there is a different hardware revision of the zbdongle-e kicking around, its hard to see how the firmware is completely broken.

[mamrai1]

I used this command on debian for flashing: universal-silabs-flasher --device /dev/ttyACM0 flash --firmware ncp-uart-hw-v7.3.1.0-zbdonglee-115200.gbl 2>&1 | tee flash.log

[mamrai1]

tried the webflasher.. same results but better logs:) silabs_flasher (1).log

[darkxst]

you needed to add --verbose, but its ok the webflasher logs look fine.

Flashing seems to go fine, but then dropping connection (probably timeout) as soon as it tries to probe

2023-08-12 09:54:39 emscripten universal_silabs_flasher.flasher[42] INFO Probing ApplicationType.EZSP at 115200 baud
2023-08-12 09:54:39 emscripten bellows.ezsp[42] DEBUG Resetting EZSP
2023-08-12 09:54:39 emscripten bellows.uart[42] DEBUG Resetting ASH
2023-08-12 09:54:39 emscripten bellows.uart[42] DEBUG Sending: b'1ac038bc7e'
2023-08-12 09:54:44 emscripten bellows.uart[42] DEBUG Connection lost: None
2023-08-12 09:54:44 emscripten bellows.uart[42] DEBUG Closed serial connection

Does the same thing happen if you try and flash the 4.3.1 multipan RCP firmware? Can you probe after installing that one?

[darkxst]

also one more test, with 7.3.1 if you connect to the dongle over serial are you getting the gecko bootloader menu or a lot of random characters?

If your on linux just run screen /dev/ttyACM0 115200

[mamrai1]

also one more test, with 7.3.1 if you connect to the dongle over serial are you getting the gecko bootloader menu or a lot of random characters?

If your on linux just run screen /dev/ttyACM0 115200

nothing just a blank screen

[mamrai1]

you needed to add --verbose, but its ok the webflasher logs look fine.

Flashing seems to go fine, but then dropping connection (probably timeout) as soon as it tries to probe

2023-08-12 09:54:39 emscripten universal_silabs_flasher.flasher[42] INFO Probing ApplicationType.EZSP at 115200 baud
2023-08-12 09:54:39 emscripten bellows.ezsp[42] DEBUG Resetting EZSP
2023-08-12 09:54:39 emscripten bellows.uart[42] DEBUG Resetting ASH
2023-08-12 09:54:39 emscripten bellows.uart[42] DEBUG Sending: b'1ac038bc7e'
2023-08-12 09:54:44 emscripten bellows.uart[42] DEBUG Connection lost: None
2023-08-12 09:54:44 emscripten bellows.uart[42] DEBUG Closed serial connection

Does the same thing happen if you try and flash the 4.3.1 multipan RCP firmware? Can you probe after installing that one?

No it works:

universal-silabs-flasher --verbose --device /dev/ttyACM0 probe 2023-08-12 13:59:06 omv asyncio[15102] DEBUG Using selector: EpollSelector 2023-08-12 13:59:06 omv universal_silabs_flasher.flasher[15102] INFO Probing ApplicationType.GECKO_BOOTLOADER at 115200 baud 2023-08-12 13:59:06 omv universal_silabs_flasher.common[15102] DEBUG Connection made: SerialTransport(<_UnixSelectorEventLoop running=True closed=False debug=False>, <universal_silabs_flasher.gecko_bootloader.GeckoBootloaderProtocol object at 0x7f2813aa2a30>, Serial(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False)) 2023-08-12 13:59:06 omv universal_silabs_flasher.common[15102] DEBUG Sending data b'3' 2023-08-12 13:59:08 omv universal_silabs_flasher.flasher[15102] INFO Probing ApplicationType.CPC at 460800 baud 2023-08-12 13:59:08 omv universal_silabs_flasher.common[15102] DEBUG Connection made: SerialTransport(<_UnixSelectorEventLoop running=True closed=False debug=False>, <universal_silabs_flasher.cpc.CPCProtocol object at 0x7f2813aa2a30>, Serial(port='/dev/ttyACM0', baudrate=460800, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False)) 2023-08-12 13:59:08 omv universal_silabs_flasher.cpc[15102] DEBUG Sending frame CPCTransportFrame(endpoint=<EndpointId.SYSTEM: 0>, control=196, payload=UnnumberedFrame(command_id=<UnnumberedFrameCommandId.PROP_VALUE_GET: 2>, command_seq=0, payload=PropertyCommand(property_id=<PropertyId.SECONDARY_CPC_VERSION: 3>, value=b''))) 2023-08-12 13:59:08 omv universal_silabs_flasher.common[15102] DEBUG Sending data b'\x14\x00\n\x00\xc4U\xd3\x02\x00\x04\x00\x03\x00\x00\x00\xdb\x12' 2023-08-12 13:59:09 omv universal_silabs_flasher.cpc[15102] DEBUG Failed to send CPCTransportFrame(endpoint=<EndpointId.SYSTEM: 0>, control=196, payload=UnnumberedFrame(command_id=<UnnumberedFrameCommandId.PROP_VALUE_GET: 2>, command_seq=0, payload=PropertyCommand(property_id=<PropertyId.SECONDARY_CPC_VERSION: 3>, value=b''))), trying again in 0.10s (attempt 1 of 4) 2023-08-12 13:59:09 omv universal_silabs_flasher.cpc[15102] DEBUG Sending frame CPCTransportFrame(endpoint=<EndpointId.SYSTEM: 0>, control=196, payload=UnnumberedFrame(command_id=<UnnumberedFrameCommandId.PROP_VALUE_GET: 2>, command_seq=0, payload=PropertyCommand(property_id=<PropertyId.SECONDARY_CPC_VERSION: 3>, value=b''))) 2023-08-12 13:59:09 omv universal_silabs_flasher.common[15102] DEBUG Sending data b'\x14\x00\n\x00\xc4U\xd3\x02\x00\x04\x00\x03\x00\x00\x00\xdb\x12' 2023-08-12 13:59:10 omv universal_silabs_flasher.cpc[15102] DEBUG Failed to send CPCTransportFrame(endpoint=<EndpointId.SYSTEM: 0>, control=196, payload=UnnumberedFrame(command_id=<UnnumberedFrameCommandId.PROP_VALUE_GET: 2>, command_seq=0, payload=PropertyCommand(property_id=<PropertyId.SECONDARY_CPC_VERSION: 3>, value=b''))), trying again in 0.10s (attempt 2 of 4) 2023-08-12 13:59:10 omv universal_silabs_flasher.cpc[15102] DEBUG Sending frame CPCTransportFrame(endpoint=<EndpointId.SYSTEM: 0>, control=196, payload=UnnumberedFrame(command_id=<UnnumberedFrameCommandId.PROP_VALUE_GET: 2>, command_seq=0, payload=PropertyCommand(property_id=<PropertyId.SECONDARY_CPC_VERSION: 3>, value=b''))) 2023-08-12 13:59:10 omv universal_silabs_flasher.common[15102] DEBUG Sending data b'\x14\x00\n\x00\xc4U\xd3\x02\x00\x04\x00\x03\x00\x00\x00\xdb\x12' 2023-08-12 13:59:11 omv universal_silabs_flasher.cpc[15102] DEBUG Failed to send CPCTransportFrame(endpoint=<EndpointId.SYSTEM: 0>, control=196, payload=UnnumberedFrame(command_id=<UnnumberedFrameCommandId.PROP_VALUE_GET: 2>, command_seq=0, payload=PropertyCommand(property_id=<PropertyId.SECONDARY_CPC_VERSION: 3>, value=b''))), trying again in 0.10s (attempt 3 of 4) 2023-08-12 13:59:11 omv universal_silabs_flasher.cpc[15102] DEBUG Sending frame CPCTransportFrame(endpoint=<EndpointId.SYSTEM: 0>, control=196, payload=UnnumberedFrame(command_id=<UnnumberedFrameCommandId.PROP_VALUE_GET: 2>, command_seq=0, payload=PropertyCommand(property_id=<PropertyId.SECONDARY_CPC_VERSION: 3>, value=b''))) 2023-08-12 13:59:11 omv universal_silabs_flasher.common[15102] DEBUG Sending data b'\x14\x00\n\x00\xc4U\xd3\x02\x00\x04\x00\x03\x00\x00\x00\xdb\x12' 2023-08-12 13:59:12 omv universal_silabs_flasher.cpc[15102] DEBUG Failed to send CPCTransportFrame(endpoint=<EndpointId.SYSTEM: 0>, control=196, payload=UnnumberedFrame(command_id=<UnnumberedFrameCommandId.PROP_VALUE_GET: 2>, command_seq=0, payload=PropertyCommand(property_id=<PropertyId.SECONDARY_CPC_VERSION: 3>, value=b''))), trying again in 0.10s (attempt 4 of 4) 2023-08-12 13:59:12 omv universal_silabs_flasher.flasher[15102] INFO Probing ApplicationType.CPC at 115200 baud 2023-08-12 13:59:12 omv universal_silabs_flasher.common[15102] DEBUG Connection made: SerialTransport(<_UnixSelectorEventLoop running=True closed=False debug=False>, <universal_silabs_flasher.cpc.CPCProtocol object at 0x7f2813aabdc0>, Serial(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=0, xonxoff=False, rtscts=False, dsrdtr=False)) 2023-08-12 13:59:12 omv universal_silabs_flasher.cpc[15102] DEBUG Sending frame CPCTransportFrame(endpoint=<EndpointId.SYSTEM: 0>, control=196, payload=UnnumberedFrame(command_id=<UnnumberedFrameCommandId.PROP_VALUE_GET: 2>, command_seq=0, payload=PropertyCommand(property_id=<PropertyId.SECONDARY_CPC_VERSION: 3>, value=b''))) 2023-08-12 13:59:12 omv universal_silabs_flasher.common[15102] DEBUG Sending data b'\x14\x00\n\x00\xc4U\xd3\x02\x00\x04\x00\x03\x00\x00\x00\xdb\x12' 2023-08-12 13:59:12 omv universal_silabs_flasher.common[15102] DEBUG Received data b'\x14\x00\x16\x00\xc4W\xe5\x06\x00\x10\x00\x03\x00\x00\x00\x04\x00\x00\x00\x03\x00\x00\x00\x01\x00\x00\x00\r\x14' 2023-08-12 13:59:12 omv universal_silabs_flasher.cpc[15102] DEBUG Parsed frame UnnumberedFrameType.POLL_FINAL CPCTransportFrame(endpoint=<EndpointId.SYSTEM: 0>, control=196, payload=UnnumberedFrame(command_id=<UnnumberedFrameCommandId.PROP_VALUE_IS: 6>, command_seq=0, payload=PropertyCommand(property_id=<PropertyId.SECONDARY_CPC_VERSION: 3>, value=bytearray(b'\x04\x00\x00\x00\x03\x00\x00\x00\x01\x00\x00\x00')))) 2023-08-12 13:59:12 omv universal_silabs_flasher.flasher[15102] INFO Detected ApplicationType.CPC, version '4.3.1' at 115200 baudrate (bootloader baudrate None)

[mamrai1]

Probing rcp firmware works, screen show just a blank screen with that also but that is normal i think.. With ezsp firmware, no probe and screen also blank.

[wastez]

Probing rcp firmware works, screen show just a blank screen with that also but that is normal i think.. With ezsp firmware, no probe and screen also blank.

I also think that the blank screen on rcp is normal because it’s not driven directly by the serial device. So the problem seems to be the ncp 7.3.1 firmware…..

[darkxst]

screen wont show anything useful in either ncp or rcp, only if the device is stuck in bootloader it will show a menu

[mamrai1]

@darkxst have you ever flashed the nvm3 file on the sonoff you used to check the firmware? I did. Maybe something got erased which was not supposed to be?

[wastez]

@darkxst have you ever flashed the nvm3 file on the sonoff you used to check the firmware? I did. Maybe something got erased which was not supposed to be?

But I did not flash the nvm3 file and have the same problem…..

[darkxst]

@darkxst have you ever flashed the nvm3

yes, I have used it occasionally when downgrading back to 6.10.3 factory firmware...

[darkxst]

which firmware build are you using that does work?

[mamrai1]

7.1.1.0 build 273

[darkxst]

7.1.1.0 build 273

Yes, I've seen the version number in the logs, but whose build, which repo?

[mamrai1]

Xsp1989

[mamrai1]

firmware714.zip Weird.. Attached 2 files of 7.1.4 from @xsp1989 . Old version works but not the new one.

[darkxst]

You mean these? hw one is for zb-gw04 https://github.com/xsp1989/zigbeeFirmware/commit/f813621c63519a289e6f315157e9fe2f8f8fbd96

[wastez]

As far as I know the 7.1.1 was too from xsp1989 but he removed them.

One of the last changes he made was to set the default transmit power to 20 dbm.

[mamrai1]

You mean these? hw one is for zb-gw04 xsp1989/zigbeeFirmware@f813621

Yes there is a a version with sw flowcontrol. As stated above the latest doesn't work. Attached zip file with both versions. firmware714.zip

[wastez]

@darkxst So if you now flash your 7.3.1 it will work without problems? Have somebody tried a other version of 7.3.1? (higher baudrate for example)

[darkxst]

So if you now flash your 7.3.1 it will work without problems?

yes, I flashed it the other day and it booted fine and worked in Z2M.

Zigbee2MQTT:info 2023-08-13 23:15:21: Coordinator firmware version: '{"meta":{"maintrel":"1 ","majorrel":"7","minorrel":"3","product":12,"revision":"7.3.1.0 build 176"},"type":"EZSP v12"}'

[darkxst]

Attached zip file with both versions.

The firmware hasnt changed on git. It was released Apr 27. so why are the two downloads different?

[mamrai1]

It was removed and re released 27 Apr...

https://github.com/xsp1989/zigbeeFirmware/commit/1b36577b36f14dd4a99c2abf00c0850028bd852a

commit 1b36577

[darkxst]

that 7.1.4.new flashes and probes ok on my dongle, but has other issues failing in Z2M

[wastez]

that 7.1.4.new flashes and probes ok on my dongle, but has other issues failing in Z2M

Thats exactly what i had.....

But not that they are not working at all like the 7.3.1.

Edit: By the way whats the difference in your firmware beetween normal and -none version?

[darkxst]

But not that they are not working at all like the 7.3.1.

I just flashed my 7.3.1 again (from a fresh download), after 7.1.4 failed and it was fine, again...

By the way whats the difference in your firmware beetween normal and -none version?

normal has software (xon/xoff) flow control set same as itead builds (this only applies to NCP builds) -none has flow control turned completely off

[wastez]

Tried it again and the same happening, here the log:

silabs-log.txt

Everthing looks good but probing is not possible.

Direct serial connection is empty.

[wastez]

Here is the probing log: probe.txt

[wastez]

Flashed the old firmware and all is as it should......

[mamrai1]

Flashed the old firmware and all is as it should......

Which one?

[wastez]

Flashed the old firmware and all is as it should......

Which one?

Again the 7.1.1.

[mamrai1]

@wastez where did you buy your stick from? Is the serial number similar to 20220811181546?

[wastez]

@mamrai1 I ordert it from amazon. I dont´t know the serial, can't see it in z2m. Have to search for it.

I think this is my serial: 202208161613231

[mamrai1]

Tim on your firmware power is hardcoded to 20db? If so maybe power issues with cable, or usb port or position of the stick?

[wastez]

@darkxst

Could it be that your stick has a other bootloader for example? (Sorry i don't know much about these things in ezsp sticks and how they work)

I think about it because @mamrai1 stick seems to be pretty produced close to mine.

[mamrai1]

that 7.1.4.new flashes and probes ok on my dongle, but has other issues failing in Z2M

Sorry you are right. Flashes ok on mine too.. Maybe i had the same problem from 7.2.2.0 to 7.2.3.0. It was a long time ago and can't really remember.

[wastez]

@darkxst

I saw something on the end of the flash process with 7.3.1 the following was sent: 2023-08-13 15:37:33 Vortex-i5.local universal_silabs_flasher.xmodemcrc[84506] DEBUG Sending data b'\x01\x1f\xe0sp_version": "7.3.1.0"\n}\n\xfc\x04\x04\xfc\x04\x00\x00\x00\xf0\xda\xb1\xdf\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xf3\x86' (attempt 0)

And with 7.1.1 this was sent: 2023-08-13 15:54:27 Vortex-i5.local universal_silabs_flasher.xmodemcrc[84903] DEBUG Sending data b'\x01\x1b\xe4\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xfc\x04\x04\xfc\x04\x00\x00\x00\xdf\x95T~\xff\xff\xff\xff\xff\xff\xff\xffd\xd4' (attempt 0)

Is this correct on 7.3.1? Shouldn't it be all hex?

Edit: This is the 7.1.1 we were speaking about: https://github.com/xsp1989/zigbeeFirmware/blob/edf2a0d3a717373764ec0673d4fecb0b882a636a/firmware/Zigbee3.0_Dongle-NoSigned/EZSP/ncp-uart-sw_7.1.1.0_115200.gbl

[darkxst]

Is this correct on 7.3.1? Shouldn't it be all hex?

That is correct, its the metadata that is embedded on all my firmware builds

[darkxst]

Could it be that your stick has a other bootloader for example?

My stick also shows bootloader v1.12. The only thing that could really affect the bootloaded is was if its set to only accept signed images, but that is not the case on any -E dongles. Otherwise the RCP image would have failed also.

my serial: 202208161613231

if that is a date code, the dongle I am currently testing is about 3 months newer than that.

Tim on your firmware power is hardcoded to 20db? If so maybe power issues with cable, or usb port or position of the stick?

power is left at default, which I believe is 20dBm for EFR32 although I havent specifically checked. I wouldnt expect that to be causing power issues and failing boots

Maybe i had the same problem from 7.2.2.0 to 7.2.3.0.

Did 7.2.2 work? it would be good to know the exact version that broke, then I can check release notes for SDK and see if anything relevant changed. However its also possible it was triggered by a tooling change in the silabs slc tools, which are not documented well.

[darkxst]

Also can you try this firmware? https://github.com/darkxst/silabs-test/raw/7.1/firmware_builds/zbdonglee/ncp-uart-hw-v7.1.5.0-zbdonglee-115200.gbl

This is built with same configs as my 7.3.1

[mamrai1]

Also can you try this firmware? https://github.com/darkxst/silabs-test/raw/7.1/firmware_builds/zbdonglee/ncp-uart-hw-v7.1.5.0-zbdonglee-115200.gbl

This is built with same configs as my 7.3.1

Flashing goes ok but fails to probe flash715.log probe715.log