Write custom EUI64 to NV3 storage if available

[puddly]

From the Gecko SDK 4.3.0 release notes:

Zigbeed now includes an implementation of emberGetRestoredEui64() which loads the CREATOR_STACK_RESTORED_EUI64 token from the host_token.nvm file.

This finally bypasses the dreaded i_understand_i_can_update_eui64_only_once_and_i_still_want_to_do_it limitation, allowing for a coordinator's IEEE address to be overwritten without any issues.

---

TODO:

• [x] Test with RCP firmware with zigbeed: works with the latest Gecko SDK release (v4.3.0).
• [x] Does it actually work? Is this IEEE address actually used in all tables and during network management?
• [x] Investigate if this works with NCP firmware (probably requires the NV3 component to be compiled into the firmware)

[MattWestb]

I think in GSDK 4.3.0.0 / EZSP 7.3.0.0 (or it was in the RCP part on the host side) its shall being possible loading it from software but i was not reading the dilates but it was very mush deep thing that only you can knowing how its working and if its possible implanting. One thing is that they starting encrypting the key storage but i think we is reading it with commands that if doing it transparent.

Edit: I was not reading all and its looks you have implanting it !!!

Great work done as normal !!

[agners]

From the Gecko SDK 4.3.0 release notes:

Zigbeed now includes an implementation of emberGetRestoredEui64() which loads the CREATOR_STACK_RESTORED_EUI64 token from the host_token.nvm file.

Isn't that referring to the Multiprotcool/Multi-PAN setup only (as in with zigbeed?

This finally bypasses the dreaded i_understand_i_can_update_eui64_only_once_and_i_still_want_to_do_it limitation, allowing for a coordinator's IEEE address to be overwritten without any issues.

So how does that work/relate with regular NCP controllers using the EmberZNet stack running on the micro-controller?

[puddly]

@agners The most recent commit implements it for NCP firmware. Corresponding PR for the firmware builder: https://github.com/NabuCasa/silabs-firmware-builder/pull/22

I've yet to actually test these in a real network beyond ensuring the IEEE persists through backup and restore.

[codecov[bot]]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (b487136) 99.76% compared to head (02da6c5) 99.76%.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## dev #565 +/- ## ======================================== Coverage 99.76% 99.76% ======================================== Files 62 62 Lines 4602 4713 +111 ======================================== + Hits 4591 4702 +111 Misses 11 11 ``` | [Impacted Files](https://app.codecov.io/gh/zigpy/bellows/pull/565?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=zigpy) | Coverage Δ | | |---|---|---| | [bellows/ezsp/v10/commands.py](https://app.codecov.io/gh/zigpy/bellows/pull/565?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=zigpy#diff-YmVsbG93cy9lenNwL3YxMC9jb21tYW5kcy5weQ==) | `100.00% <ø> (ø)` | | | [bellows/ezsp/v9/commands.py](https://app.codecov.io/gh/zigpy/bellows/pull/565?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=zigpy#diff-YmVsbG93cy9lenNwL3Y5L2NvbW1hbmRzLnB5) | `100.00% <ø> (ø)` | | | [bellows/ezsp/\_\_init\_\_.py](https://app.codecov.io/gh/zigpy/bellows/pull/565?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=zigpy#diff-YmVsbG93cy9lenNwL19faW5pdF9fLnB5) | `99.29% <100.00%> (+0.09%)` | :arrow_up: | | [bellows/types/basic.py](https://app.codecov.io/gh/zigpy/bellows/pull/565?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=zigpy#diff-YmVsbG93cy90eXBlcy9iYXNpYy5weQ==) | `100.00% <100.00%> (ø)` | | | [bellows/types/named.py](https://app.codecov.io/gh/zigpy/bellows/pull/565?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=zigpy#diff-YmVsbG93cy90eXBlcy9uYW1lZC5weQ==) | `100.00% <100.00%> (ø)` | | | [bellows/types/struct.py](https://app.codecov.io/gh/zigpy/bellows/pull/565?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=zigpy#diff-YmVsbG93cy90eXBlcy9zdHJ1Y3QucHk=) | `100.00% <100.00%> (ø)` | | | [bellows/zigbee/application.py](https://app.codecov.io/gh/zigpy/bellows/pull/565?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=zigpy#diff-YmVsbG93cy96aWdiZWUvYXBwbGljYXRpb24ucHk=) | `100.00% <100.00%> (ø)` | |

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.

[puddly]

I migrated my home network to an old SkyConnect that has already had its EUI64 replaced with an incorrect value. Everything works fine so far with the NV3 token storage after flashing 7.3.0.0 NCP with the extra component.

[dmulcahey]

Nice!!

[MattWestb]

@puddly If you is having one SWD probe you can writing one empty file to the "userdata" or erasing the flash pages with command and the token of the burned is going away and can being burned agen.