[REQUEST] Ability to upgrade flash Texas Instrument CC2530 and CC2531 firmware via its bootloader interface

@JelmerT Requesting this now as @puddly posted in https://github.com/zha-ng/zigpy-znp/issues/14 saying that he implemented the MT command based serial bootloader protocol (f67e8a4) implemented in CC2530 and CC2531 bootloader interface as used by the SerialBootTool (Windows only) utility by Texas Instruments mentioned in Koenkk/zigbee2mqtt#320 into zigpy-znp.

zigpy-znp is new open-source TI ZNP 3.x client written in Python that is in early development for zigpy and ZHA in Home Assistant. For more information check out https://github.com/zha-ng/zigpy-znp/

zigpy-znp developer was able to backup (read) and upgrade (write) flash his already pre-flashed Texas Instruments CC2531 adapter with a newer firmware without using any external tools, so as a standalone application to flash an adapter (in his case he tested it with a CC2531 adapter from ITead which is now known to be shipped with an older firmware from the factory)

• https://github.com/zha-ng/zigpy-znp/commit/f67e8a48f9a0f9bcf400a6229e2d14b82c3aae70

ip install zigpy-znp
$ python -m zigpy_znp.tools.flash_read /dev/serial/by-id/radio -o flash.bin
$ python -m zigpy_znp.tools.flash_write /dev/serial/by-id/radio -i flash.bin

Suggest considering adding the ability to upgrade these older Texas Instrument CC2530 and CC2531 coordinator firmware via cc2538-bsl to make it also compatible with those as well.

(TI’s rialBootTool which also comes with IAR can otherwise be download separately here http://processors.wiki.ti.com/index.php/File:SerialBootTool_1_3_2.zip ).

[puddly]

Finally got it: the CRC is computed by skipping the two pairs of CRC bytes: https://github.com/zha-ng/zigpy-znp/blob/7e9367480ec3a7602c215c59c27a9bafe604a28b/zigpy_znp/tools/flash_write.py#L21-L56

At this point the implementation in zigpy_znp.tools.flash_write is stable-ish.

I do like having things be as fool-proof as possible, so people don’t lock themselves out. Which seems an issue with this bootloader, since its even pretty hard to figure out which chip exactly you’re talking to?

The bootloader won’t let you overwrite itself so you probably won’t get locked out but if you manage to catch the chip while it’s still in its bootloader, you should be able to tell a little bit about what chip you’re talking to:

==>  UBL.HandshakeReq.Req()  # b'\xFE\x00\x4D\x04\x49'
<==  UBL.HandshakeRsp.Callback(  # b'\xFE\x12\x4D\x84\x00\x00\x00\x00\x00\x02\x40\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x91'
         Status=<BootloaderStatus.SUCCESS: 0>,
         BootloaderRevision=0,
         DeviceType=<BootloaderDeviceType.CC2530: 2>,  # it's hard to tell from the source code what this really is
         BufferSize=64,
         PageSize=2048,
         BootloaderCodeRevision=0
     )

Otherwise, you can ask the device if it even has a bootloader after it has booted by sending it a SYS.Version request. The response looks like this:

==>  SYS.Version.Req()
<==  SYS.Version.Rsp(
         TransportRev=2,
         ProductId=1,
         MajorRel=2,
         MinorRel=7,
         MaintRel=1,
         CodeRevision=20200417,
         BootloaderBuildType=<BootloaderBuildType.NON_BOOTLOADER_BUILD: 0>,
         BootloaderRevision=4294967295
     )

You might be able to send a hard reset request and have the device jump back into bootloader, though this might just restart the application code instead. Implementing the five or so MT commands is doable but it will take a little bit of work to get the command framing and parsing working.

[JelmerT]

Sorry for the delay on this.

I’m open to PRs to support this bootloader. As long as current features and functions of the already supported chips aren’t changed and implementation is as user friendly as possible (read “it just works”).

I currently don’t have the bandwidth to do any active development on this though. I can do code review.