You have a second MCU or other data files you want to OTA via Z-Wave. How can you reuse the Bootloader firmware to verify the signature and decrypt the data?
The code to verify and decrypt the file already exists in the bootloader and is known good. Reusing the existing bootloader code is smaller and safer than re-inventing the wheel - or in this case encryption.
The attached project is a modified Z-Wave Door Lock Key Pad sample application that demonstrates how to OTA code/data other than the Z-Wave firmware. OTA of the Z-Wave firmware works in the sample application already - but first the encryption keys MUST be generated. See https://www.silabs.com/community/wireless/z-wave/knowledge-base.entry.html/2019/04/09/z-wave_700_ota_ofe-i00M on how to generate the keys. See the two .BAT files in the comments section which will run all the necessary commands for you. They are also included in this .sls file in the KEYS directory. You MUST create your own project keys to OTA either the Z-Wave Firmware or any other data.
To OTA other types of files you need to start with a binary file. Most microprocessor development environments will output a binary file so use that instead of a HEX file. If you have an Intel hex or Mototola S record file, use a utility like SREC_CAT to convert it to a binary file. SREC_CAT can convert just about any file type into any other file type. If the file is more than 200K bytes, you will need to break the file into 200K or smaller files and OTA each, one at a time. Doing that is beyond the scope of this project. Note there is no need to encrypt the file. We will be using Commander to sign and encrypt it using the keys generated here.
Changes to the SSv4 DoorlockKeyPad sample project are indicated with the comment "AKER" - search for these to find what changed. You can also diff the files with a fresh copy of the DoorLockKeyPad sample app from SSv4. Most of the code to support OTA of an external processor is in this file. A few changes have been made to ota_util.c in ZAF_CommandClasses_FirmwareUpdate but these are expected to be included in a future release of the SDK (currently tested on 7.13).
Commander is used to generate a pair of public and private keys. The private key is then programmed into every device to be OTAed. Commander then encrypts and signs the binary file and wraps it with bootloader tokens. The gbl file is downloaded, the signature checked and the encrypted data is then passed to a callback function 64 bytes at a time. You then have to store the data or pass it to the external MCU. This example simply prints the data out a UART.
There two .BAT files in the KEYS directory for this project. These are windows script files. For other platforms you can easily convert them to the platform specific commands. See the comments in the files for more details. In a windows shell type:
This will use Commander to generate a project set of keys in the files vendor_*.*. Only execute this command ONCE. The same keys are used for the duration of the project. If you change the keys then you cannot OTA the devices as the keys no longer match.
Each device manufactured must have the private key programmed into FLASH. Use the PgmToken.bat to program the key into a target device connected via USB. Note that EVERY unit manufactured must have these keys programmed into it.
Create the .gbl file from the binary file using the following command:
commander gbl create <OTA_FileName>.gbl --metadata <BinaryFile> --sign vendor_sign.key --encrypt vendor_encrypt.key
The --metadata option will wrap the binary data with the necessary tokens for the bootloader to parse the data. Do not use the --compress option. If the data needs to be compressed, use your own algorithm for that. There are 3 sample binary files in the KEYS directory - a small .WAV audio file, a large .M4A audio file and a PNG image file. Use the command above to wrap the file with the necessary tokens for OTA.
Use the PC Controller or other application to send the gbl file over Z-Wave. Once the entire file has been sent and the CRC checked to be good, the FinishFwUpdate function is called to begin processing the image. Note that in the PCC you have to first GET the Current Firmware, then select the Target: 1 to download the metadata. Then click on UPDATE and the OTA will begin. Connect a terminal to the VCOM port of the WSTK to view the data streaming down during the OTA. Once all the data is sent down, the signature is checked and the decrypted data is sent out the UART. This is where you would need to change the code to store the data instead of printing it out the UART.
The bootloader_verifyImage() function is called and the metadataCallback function is passed in. bootloader_verifyImage first returns a zero if the signature matches. If the signature fails an error value is returned giving some details on why it failed. The time to verify the signature can be fairly long depending on the size of the image so the watchdog timer is disabled during the processing.
The function passed in to bootloader_verifyImage is called with a pointer to the data and the number of bytes in each block. The size of the block can vary up to 64 bytes. In this example the data is simply printed out the UART. In your application you would replace this function with code to store the data as needed on the other MCU or external NVM.
It is recommended to reboot after the image data has been stored to ensure the FLASH is cleaned up properly. The current demo however does not reboot.
Note: This is an SSv4 SDK 7.13 sample but the same concepts should work in SSv5. The changes to ota_util.c will be folded into the SDK in a future release but for now those changes are necessary.
CTUNE is used to adjust the load capacitance of Silicon Labs Wireless Gecko (EFR32™) portfolio devices crystal oscillator (HFXO).
The crystal frequency is 39 MHz for Z-Wave 700 platform, refer to INS14487 Z-Wave 700 Integration Guide for recommended crystal when using EFR32ZG14 SoC.
It is mandatory to calibrate the crystal for Z-Wave 700 product based on EFR32ZG14 device to ensure the frequency of each product is correct. All ZGM130S modules integrate internal 39 MHz crystal, and are calibrated during production.
The CTUNE calibration procedure is described in INS14498 Mandatory crystal adjustment for EFR32ZG14 based products. To be short:
1. Program a RailTest firmware which is built for EFR32ZG14. More info about how to create a RailTest project in Simplicity Studio for Z-Wave 700, please refer to KB - Create a RailTest project for ZGM130S.
2. Adjust CTUEN value by sending RailTest command 'setCtune 0xYYY' via UART interface. Please follow the procedure described in INS14283 Bing-up/test HW development, section 4.5.6 How to Fine-Tune the System Crystal Using RailTest.
3. Measure RF carrier wave (CW) frequency offset.
4. Repeat step 2 and 3 until the CW average frequency error is adjusted to be within +/-1 ppm for each product.
5. The CTUNE value is incorporated into the Z-Wave protocol. Once a valid CTUNE value is found for the specific product, write it into the CTUNE manufacturing token (TOKEN_MFG_CTUNE) in Flash memory, User Data page. This is can be done by using Simplicity Commander ctune set command.
$ commander ctune set <value>
More information using Simplicity Commander, see UG162 Simplicity Commander Reference Guide, section 6.16 CTUNE Commands.