You’ve finished designing a new PCB for your Z-Wave product and are now ready to start testing with your own custom firmware. Well, the first thing you need are bootloaders. The bootloader is a standalone application that handles upgrading the application firmware among other things. Downloading a bootloader into a Silicon Labs devkit is easy, just click on “run”. But for custom PCBs you must build it from the source code. There are two types of bootloaders needed: One for End Devices which will receive the updated firmware image over the radio, the other is for Controllers which will receive the image via the UART wires. These are similar but there are a few important differences. This post is specifically for the Z-Wave 800 series and GSDK 4.4.1. Hopefully the process will be a little easier in a future release.
End Device Bootloader – OTA
Fortunately the End Device bootloader is easy with the release of GSDK 4.4.1 (Z-Wave 7.21.1). Plug your board into a ProKit (WSTK) via the Tag-Connect connector. The WSTK should show up in Simplicity Studio v5 (SSv5) Launcher Perspective with “custom board” and the EFR32ZG23 part number on your board. Click on Detect Target if not. Ensure the Debug Mode is set to Mini (or OUT for WSTK1). Select the debug adaptor then start the New Project Wizard via File->New. Make sure the latest SDK is selected and GCC12 (not GCC10). Click on Z-Wave to filter the list and uncheck Solution Examples. Scroll down to “Bootloader – SoC Internal Storage (For Z-Wave Applications)” and select that. Click Next then rename the project to something more meaningful with the chip (ZG23A) and GSDK version (_411 for 4.1.1) for example. Build the project which should complete without error. The bootloader has a lot of security options but I recommend using the defaults. If you have a complex device and need additional code space, you can relocate the OTA buffer to an off-chip serial flash chip which will free up nearly 200K of FLASH space but no additional RAM.
Controller Bootloader – OTW
This example uses a custom PCB and the EFR32ZG23A (mid-security) chip. I start with this combination as that is what most customers will start with. Using one of the devkits causes SSv5 to automagically “know” all sorts of things about the board and what GPIOs are wired to what and what other features are available. When you pick this chip, there are zero pre-built “demos” as all of the current devkits have B (high-security) parts on them.
Start the New Project Wizard via File->New. Ensure the IDE/Toolchain is GCC12 and not GCC10. scroll down and click on the “Bootloader – NCP UART XMODEM (for Z-Wave Applications)” then click on Next. This will create a project called bootloader-storage-internal-single-zwave then append the GSDK version to that which in this case is 4.4.1 so add “ZG23A_441” to the project name to keep track of which chip and which GSDK this is for. Click on Finish then build the project. This will fail because SL_SERIAL_UART_PERIPHERAL_NO is not defined as well as several other things related to the UART.
Clearly the UART needs to be configured but a guide is needed to figure out what that might be. Plug in a Devkit and build the same project but with a different name. This project builds just fine so search for SL_SERIAL_UART_PERIPHERAL_NO. btl_uart_driver_cfg.h has a define for this for USART0. The same file in the custom project says “bootloader UART peripheral not configured”. Obviously somehow it needs to be configured. The .slcp file has Platform->Bootloader->Drivers->Bootloader UART Driver configured.
We don’t need RTS/CTS as they are not used. Configure the custom project with USART0, RX=PA09 and TX=PA08 then the project compiles. This should be the default since you MUST use a UART for XMODEM. Maybe a future release will fix this! There are other configuration items under the Bootloader Core component but generally these can remain at the defaults.
Conclusion
Bootloaders are critical to being able to field-upgrade the firmware of any Z-Wave product which is mandatory for certification. See the Bootloader Users Guide (UG489) for more details on the many options available. The process to create the Z-Wave bootloaders is a bit more complicated than it should be but I hope this guide will bring your Z-Wave product to market a little quicker. Let me know what you think by commenting below.
DrZWave 
Hi Erick
Hope you are doing well
I got a question about creating a GBL file and applying it as an OTA.
This is the step by step im following using a ZGM230s module and a WSTK
1. Apply OTA bootloader, Z-Wave ota BRD4205B Bootloader then flash sample keys.
Those keys are stored by default in SSV5 path
C:UserssebasSimplicityStudioSDKsgecko_sdkprotocolz-waveplatformSiliconLabsPALBootLoadersample-keys
2. Create on/off project and make sure it works and pairs in a PC controller.
3. Modify app version from 1 to 2 (from zw_version_config.h file)
4. create GBL using command prompt, like:
commander.exe gbl create OTASwitch_on_off.gbl –app “C:UserssebasSimplicityStudiov5_workspacev9OTAswitch_on_offGNU ARM v12.2.1 – DefaultOTASwitch_on_off.hex” –sign sample_sign.key –encrypt sample_encrypt.key –compress lz4
5. Apply OTA using GBL file However, every time I tried to apply this OTA from the pc controller, I got the status
Status: does not match the Firmware Target=0x04
Do you know if Im missing something during the flashing steps ?
Im been following this guide too
https://community.silabs.com/s/article/z-wave-700-ota-of-end-device?language=en_US
Thanks in advance
LikeLike
You need to first create your own set of keys. Do NOT use the “sample_sign.key files. Follow the examples in the Community forum or my blog: https://drzwave.blog/2020/09/24/how-to-ota-a-co-processor-via-z-wave/
It is unfortunate that if there is ANY error in the OTA, you only get Error=0x04. It would be super helpful if Silabs would give a little more detail on why it failed – did the key fail to decrypt? Did the signature fail to match? Was there an error in transmission? So many possible errors but all we get is 0x04.
Try turning off the Version Check in the bootloader. Then you don’t have to increment the version. Also note that incrementing the Patch does NOT pass the increment check (XX.YY.ZZ – incrementing .ZZ does NOT pass the check).
LikeLike
Hi Eric,
Thanks for uncovering and sharing the Z-Wave OTW bootloader project build issue starting with chip without a devkit.
We have solved the issue and it will be fixed in the next sisdk-2024.12 (Z-Wave SDK 7.23.0) release.
LikeLike
Dear DrZwave
My name is Bainc, come from App Teams of Siliconlabs partner (FPT)
Thank you for your posting.
I have one case which relate the OTA with SPI external flash.
My setup as:
Board: BRD4204D-A00 (include WSTK)
SDK: Gecko sdk v4.4.6 and Simplicity v2024.12.1
Bootloader: bootloader-storage-spiflash-single example
Application: zwave_soc_switch_on_off example
Although, we don’t config anything more from example, there is 0x04 error code.
I try to find-out something, but there is no information.
So, could you please give me some advise?
Sorry for your busy time.
Kind regards,
Bainc
LikeLike
OTA errors are very hard to debug! They either work, or they don’t and each try takes several minutes to OTA.
Unfortunately Silabs lumps all OTA errors into a single error code = 0x04. So they give you no additional help in figuring out what is wrong. Expanding the errors has been a request for several YEARS to at least give us a clue! They could expand the errors to let you know if: the signature is wrong, the encryption failed, the firmware ID is wrong, the ota data is corrupt and probably a bunch of other potential errors. You can debug the code (I recommend using Trace and Ozone) and try to narrow down exactly what the failure is by seeing where in the OTA process the Silabs firmware errors out (in the signature check code, or decryption or somewhere else).
The most common problem is that the signature or encryption keys are wrong.
Follow: https://community.silabs.com/s/question/0D58Y00008bjCWjSAM/how-to-ota-a-zwave-800-series-enddevice?language=en_US
to ensure you’ve created AND programmed the proper keys into the DUT.
The DUT needs the keys programmed into it (each unit gets the same key) AND the application must be built using the same key (the GBL needs to be created using the key).
LikeLike
Dear DrZwave
Thank you for your reply.
I agree with you, this is a generic error code.
It is not much meaning.
So, let me take debug more detail.
I think there is problem with image verify process.
Sorry for your busy time.
Kind regards,
Bainc
LikeLike