-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
please help with recovery #28
Comments
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 |
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. |
In silabs docks i have not finding any way doing that only deleting all keys in the key token storage with EZSP commands. 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. |
Tried some other methods to downgrade back to 6.10.x but none seem to work so far. 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 |
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). 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. |
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. |
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: 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:
The SkyConnect bootloader version is "already"
I've used both agners |
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:
= 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. |
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. 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 !! |
@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. |
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
|
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. |
Hi, @TheJulianJES , Thanks alot it worked. Hold the upper button and plugged in. THX |
@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. |
Hi @xsp1989 , first of all thank you soooo much for your reply!
|
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. |
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? |
@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: |
@TheJulianJES Still no J-Link on your desktop ?? |
@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? |
@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? |
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 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. |
flash map: Areas other than the bootloader can be erased or overwritten. 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 |
What is the end of the app then being flashed (start is 0x4000 after the bootloader last flash page ends at 0x3fff) ? BANK0 = main flash for bootloader and app. The chip original IEEE is burned in the chip hardware conf aria and cant being manipulated after it have left the factory. |
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. |
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). |
By the way from commander \tokens\Readme.txt:
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. |
@MattWestb @gleba |
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: Thanks a million @xsp1989 @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. |
THX @Arc86 , @MattWestb , @xsp1989 today I've tried to downgrade my ITLEAD Dongle with the elelabs tool, but had no success. Thx
|
Then getting the If not have pressing 1 and getting the |
Thanks @MattWestb , I've tried it but did not succeed, see the result below. |
No flow control for bootloader mode. |
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. |
So, now I'm one step closer AND Finally
But now I get this error Message in Openhab. :-(
the ncpstate shows quite empty values
|
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 |
@Arc86 , where can I find the original firmware? |
this one actually the other one is the router firmware |
The fix is as follows:
|
Great @FranzSchi !! Glad to see our user is getting there system up and running beside Z2M and ZHA :-))) |
yours breathtaking, guys you all rescued my dongle 🙏 |
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
can this be fixed programmatically or just recovery?
how recovery is hard?
The text was updated successfully, but these errors were encountered: