Silicon Labs firmware flashing utility in bellows?

[Hedda]

Looks like @agners is working on a Silicon Labs firmware flashing utility called "silabs-flasher" which uses zigpy bellows library:

https://github.com/agners/silabs-flasher

Would it be a good or bad idea to bundle it as a bellows CLI tool with bellows similar to zigpy-znp command-line tools bundling?

https://github.com/zigpy/zigpy-znp/blob/dev/TOOLS.md

Similarly zigpy_znp.tools feature flash operations for Texas Instruments CC2530 and CC2531 if they have a serial bootloader:

https://github.com/zigpy/zigpy-znp/blob/dev/TOOLS.md#flash-operations

Alternatively, maybe consider common unified commands of these types of CLI tools for all radio libraries into zigpy-cli instead?

https://github.com/zigpy/zigpy-cli/

That way firmware flashing utilities for different hardware would be grouped in a single binary for easier app implementations?

[agners]

I guess it could be a sub-command to the existing bellows command.

The downside is it will add dependencies. Currently xmodem and RPi for GPIO reset/BL capability.

Also I am thinking about adding CPC support (so that silabs-flasher can also enter boot-loader mode when the RCP multiprotocol firmware is running.

[MattWestb]

Bellows can connecting NCPs with network ports that many user is using that but is your code also working with OK that ?

I have hacking one automation for ESPHome that can using hardware reset and bootloader pin but our experience with EZSP is working very well with software reset and reboot to bootloader and back to NCP mode software commands and have never needing one hardware reset or bootloader pin as long having one OK running firmware in the chip and also the update is one OK firmware.

[dmulcahey]

I guess it could be a sub-command to the existing bellows command.

The downside is it will add dependencies. Currently xmodem and RPi for GPIO reset/BL capability.

Also I am thinking about adding CPC support (so that silabs-flasher can also enter boot-loader mode when the RCP multiprotocol firmware is running.

I’d personally think this would make more sense as a utility in either zhaws or in the addon for the RCP setup or both of those.

[MattWestb]

Perhaps implanting one "pause" function in ZHA for releasing the comport so can using the it for firmware update in the HA container ?

I normally changing the comport in the core.config_entries restarting HA and using bellows for doing "maintenance" of my network EZSP coordinators but then must putting it back and and restarting HA (if not the nasty bug have disabling all ZHA enteritis).

[dmulcahey]

Perhaps implanting one "pause" function in ZHA for releasing the comport so can using the it for firmware update in the HA container ?

This will be in the websocket server currently in development

[Hedda]

I’d personally think this would make more sense as a utility in either zhaws or in the addon for the RCP setup or both of those.

That would probably also make more sense in ZHA for the reason that zigpy-znp command-line tools only support flashing TI's older CC2530/CC2531 today and not newer CC1352/CC2538/CC2652 as those currently require tools like cc2538-bsl or llama-bsl:

https://github.com/JelmerT/cc2538-bsl/

https://github.com/electrolama/llama-bsl/

That is, since the zigpy project already has radio libraries to support for many different manufacturers it would be great if the same flashing utility would be modular so that it could be made to flash Zigbee adapters from Silicon Labs, Texas Instruments, Dresden Elektronik (ConBee/RaspBee), Digi XBee, and ZiGate, (as well as hopefully also Nordic Semiconductor nRF52840 in the future too).

Because I think a major downside to not sharing one flashing tool/utility for the whole zigpy project is that it makes it harder for different Zigbee implementations that use now zigpy libraries (like ZHA, Jeedom, and Domoticz) to collaborate on common code.

[agners]

Perhaps implanting one "pause" function in ZHA for releasing the comport so can using the it for firmware update in the HA container ?

I just disable the integration in the UI, execute the bellows/silabs-flasher commands, re-enable the integration, works quite nicely.

[Hedda]

FYI, noticed puddly is also developing a "Universal Silicon Labs Flasher" that uses zigpy/bellows for Silabs OTW firmware updates?

https://github.com/puddly/universal-silabs-flasher

Looks like will be used in a Home Assistant Add-on in the future for automatically flashing SkyConnect and Yellow via socat/tcp:

https://github.com/home-assistant/addons-development/pull/86

[MattWestb]

Wrong Silabs addon is using the the https://github.com/agners/silabs-flasher/ but very likely hi is cooking one updated version then hi have implanting disconnecting the comport from bellows so can flashing the NCP / RCP without restarting HA.

[Hedda]

Wrong Silabs addon is using the the https://github.com/agners/silabs-flasher/

https://github.com/home-assistant/addons-development/pull/86 does look to use https://github.com/puddly/universal-silabs-flasher with CPC support

Also I am thinking about adding CPC support (so that silabs-flasher can also enter boot-loader mode when the RCP multiprotocol firmware is running.

[MattWestb]

Im corrected then in the code is installing pip install universal-silabs-flasher==0.0.4 = Puddly

[tube0013]

$ universal-silabs-flasher --device socket://192.168.1.123:6638 --bootloader-baudrate 115200 --baudrate 115200 flash --firmware ~/Downloads/1111/MGM210PA32JIA2_ncp-uart_7.1.3TubesZB_2022.gbl
Usage: universal-silabs-flasher [OPTIONS] COMMAND [ARGS]...
Try 'universal-silabs-flasher --help' for help.

Error: Invalid value for '--device': Path 'socket://192.168.1.123:6638' does not exist.

[puddly]

It's just a validation problem with the CLI, I never tested it with a TCP coordinator. Try again with the dev version: pip install --upgrade git+https://github.com/puddly/universal-silabs-flasher.git@dev

$ universal-silabs-flasher --device socket://10.10.10.179 flash --firmware ~/Downloads/V2_MGM12P32GE_ncp-uart-sw_6.10.3.gbl
2022-11-11 13:40:44 ubuntu.local universal_silabs_flasher.flasher[67021] INFO Probing ApplicationType.GECKO_BOOTLOADER
2022-11-11 13:40:46 ubuntu.local universal_silabs_flasher.flasher[67021] INFO Probing ApplicationType.CPC
2022-11-11 13:40:50 ubuntu.local universal_silabs_flasher.flasher[67021] INFO Probing ApplicationType.EZSP
2022-11-11 13:40:53 ubuntu.local universal_silabs_flasher.flasher[67021] INFO Detected ApplicationType.EZSP, version 6.10.3.0.297
2022-11-11 13:40:53 ubuntu.local universal_silabs_flasher.flash[67021] INFO Detected running firmware ApplicationType.EZSP, version 6.10.3.0.297
V2_MGM12P32GE_ncp-uart-sw_6.10.3.gbl  [####################################]  100%

[tube0013]

seems to work but after getting to 100% it doesn't disconnect the serial and just sits there.

[puddly]

There's some weirdness with the different bootloader versions, not all of them exit the same way. Run it with -vvv verbosity and open an issue on the GitHub repo.

[MattWestb]

Then flashing is dong and no commands or X-model transfer is done for 30 seconds sen one 2 (2 = run from the boot menu) and i think all modern bootloader shall rebooting the chip to the app or alternative probing if the chip is in bootloader / RCP or NCR. If like getting little info also print the bootloader version so getting one hint.

[puddly]

Future development of SiLabs flashing is going to happen in https://github.com/puddly/universal-silabs-flasher/, this is out of scope for bellows.