-
-
Notifications
You must be signed in to change notification settings - Fork 2
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
Attempt to copy tokens from SkyConnect to SNZB07MG24 bricks adapter #11
Comments
Addition: I was able to regain control of the stick by shorting the pins and flashing one of the recovery gbls.... however, probably I was only lucky to use the correct gbl file for my stick (i kept my fingers crossed and used the "app clear" variant, as here there was only one alternative for MG24,...). It would be helpful to have some more hints in this part of the documentation. |
I'll reopen the issue as once again flashing SkyConnect NVM3 tokens to SNZB-07MG24 bricks the device. I thought from reading the docs that this should be possible and should be a relatively safe method to migrate to the newer hardware. The NVM3 backup from SkyConnect is smaller (4,1kb) than the NVM3 backup from the SNZB-07 stick beforehand (4,4kb), The original SNZB07 token backup can be re-flashed without problems.
Fot those trying to migrate: Backing up and restoring the network seems much simpler than doing the same with the tokens. Don't follow these instructions: https://github.com/nanostra/Migration-EFR32MG21-vers-EFR32MG24 |
Since the error is a timeout, it would seem the connection dropped during the restoration or something. That could affect the starting of the firmware thereafter (a NVM3 clear should be enough to recover it though). A connection issue in this scenario would indicate a very big stability problem with the connection, since there is no network to stress it, not much going on. Although, since you had troubles with the previous adapter, a clean start with the new one may be a better choice in your case, as you mentioned before...
|
As always thank you for your quick reply.
|
|
ad 1. On one computer directly, the other one with extension cable. I''m not at discord, but does the NVM3 file contain sensitive information? |
The nvm3 file contains all the network information (you can see the details using https://github.com/Nerivec/ember-zli/wiki/Utils#parse-nvm3-tokens-backup-file). You can also create a temporary private repository here on Github and invite me, if that's easier. I'd say that was likely the mesh adjusting to changes (you have to let it do its job after large changes in the network design). Depending on LQI and various other parameters, it can shuffle things around for a while. Let me know if it happens again after a couple days have passed and things have settled down. |
I created a private repo with the original NVM3 backup from the SkyConnect (the file which bricks the SNZB07MG24 when restored there) and invited you as a collaborator. |
Same nasty bug that was plaguing MG24 firmware some time ago due to binding table size config being too large. @puddly I figure you will want to know about this one... We really should get this bug reported to Silabs too. Between bricking on firmware flash if you set the size too high during build, and now bricking on tokens restore if the backup has a size for that token that's too large... that binding table definitely has a problem (which does not seem to show up for MG21)... Here are cleaned up logs, check the timings, I added ms and removed the irrelevant parts so it's easier to read. After index 48, things start to go very wrong, from 20ms between commands, to ~5sec after a while. It takes over 4min total, versus 2-3sec normally. The restore eventually finishes, but then the device no longer starts, requiring clearing the NVM3 to restore it. Binding Table 64 - bricking
Binding Table 32 - fixed file (binding table token clipped after 32 entries)
@Ra72xx thanks for the details to help with this 😉 |
Out of curiosity, why restore the NVRAM tokens directly like this, especially for the binding table? Are there any entries in it that are useful? |
This is the NVM3 backup/restore scheme per silabs (trust-center-backup). |
I tried to migrate from SkyConnect to SNZB-07MG24 as described here: #5
The backup of the old tokens (SkyConnect) went fine.
But the restoration on the new stick (MG24) ended with an error (unfortunately, I don't remember which).
The device seems still available according to "lsusb". However I cannot even enter the stick's bootloader anymore with ember-zli or the web flasher.
Is there any way to recover from this?
The text was updated successfully, but these errors were encountered: