Coding and Debugging Z-Wave Firmware
This guide provides practical insights into Z-Wave firmware development, covering coding, debugging, development environments, and power analysis tools used by professional IoT engineers. Readers will learn recommended workflows for Silicon Labs and Trident IoT SDKs, Visual Studio Code integration, sleep-current debugging, and best practices for building reliable Z-Wave devices.
Introduction
Each of the silicon vendors, Silicon Labs and Trident IoT, have their own coding and debugging tools and methods. Each vendor has training on their tools which will help you up the learning curve. In this part of the journey, I present my tips and hints to help you up that steep learning curve. The first step is to watch the training videos or read the getting started guides from each vendor. They are well worth your time. While the videos are not particularly entertaining, you can skip through some parts and watch them at 1.5x which is what I did.
Vendor Training
- Silicon Labs –Simplicity Studio 6 100: Getting Started with Simplicity Studio 6
- Trident IoT – Trident IoT SDK – GitHub
- AI Agents can find answers or even write significant amounts of code
- Each vendor has their own AI Agent available on their website
Silicon Labs Simplicity Studio 6
Moving from Simplicity Studio 5 to version 6 requires significant learning as the Integrated Development Environment (IDE) is now based on Microsoft’s Visual Studio Code instead of eclipse. While some parts are familiar, the IDE is markedly different and will take some getting used to. Simplicity Studio 6 (SSv6) is new and has a few wrinkles and rough spots that Silicon Labs will be smoothing out in the coming months. Don’t hesitate to file a case on the support portal or contact your Silicon Labs FAE for help. The first step is to install SSv6 and Visual Studio (VS) Code and the Silicon Labs extension for VS Code. Open SSv6 and you get a broad view of all the wireless protocols Silicon Labs supports, click on Z-Wave to open the list of sample applications. Pick a sample application such as Switch On/Off which is recommended to start with. I recommend using the Copy Contents option. Using the Link SDK and Copy Project Sources option limits VS Code’s ability to find and search through files. The ProjectName.slcp file will open which is where most configuration takes place. The Software Components tab is the doorway to installing command classes or peripheral drivers. Search then install and configure command classes or APIs as needed for your application. The Pin Tool shows a graphical and tabular representation of the GPIOs. The .slpb file is the post-build editor which is where the scripts for keys and OTA file creation are configured but I recommend leaving those at their defaults. Now for the big step – in the upper right corner is the Open in VS Code. Click on that to open the Microsoft tool.
Microsoft Visual Studio Code
If you have not been using VS Code already, you have been missing out and now is the time to get familiar with it. The increase in productivity is well worth the learning curve to get started. Ensure the Silicon Labs extension is installed and connected to SSv6 – you should see the Si menu on the left for the extension and a white dot in the lower right lets you know it is connected to SSv6. When you make configuration changes in SSv6, VS Code will be informed and immediately update the project.
My tips and tricks for using VS Code:
- Always press <ctrl-s> to save after editing a file!
- SSv5 would automatically save when you click on Build, VS Code does NOT
- It has taken me weeks for this to become a habit. I have been debugging for an hour only to realize the change I made is not in the download because I didn’t hit save
- Copilot AI is a huge productivity improvement – learn it – use it!
- Add a comment to any line of code by typing “//” at the end, Copilot usually produces a decent, often wordy, comment on what the code is doing
- Start typing any function, Copilot fills in the required parameters in the right format(s)
- Start typing “for”, “while” or “switch”, Copilot fills in much of a likely block of code and as you fill in more code, Copilot guesses what else you need – press TAB to accept the suggestion
- Copilot hallucinates – it is not perfect so be careful and obviously check the results
- Searching for variables or functions is different in VS Code than SSv5
- Hovering will display some information, ask Copilot for more details
- Right Click opens a popup with many options – recommend Find All References
- Use the Search menu on the left instead of the bar across the top
- In Files to Include – add “*.c,*.h” otherwise the search will include object files, .map files and other useless hits
- Note that the search is across your entire workspace so look carefully at which project the search result is in
- I sometimes still end up greping to find things
- Can’t see a file in the Si Extension? Use the Explorer tab (upper left) to see all the files
- Clean and then Build from scratch if something is not working
- From the Silabs Extension you can flash firmware, open a terminal, open commander, and other tools
- The gnudbg debugger is reliable
- but I still use Segger Ozone when I hit a really squirrely problem
- Get a new computer with at least 32GB of RAM
- SSv6 and VSCode are memory hogs
- I bought a new laptop with an i9 CPU and 32GB which made the experience more efficient and stable
Trident IoT
Trident takes a quite different approach to embedded programming than Silicon Labs. Building a project, compiling and flashing are done using their command line tool called “Elcap”. Elcap relies on Docker or Podman containers to make for a unified development environment regardless of the platform: Windows, Linux or Mac. Trident has a VS Code plugin called “TIDE” which makes for a familiar environment for writing and exploring the embedded code. These features make for frictionless setup as the environment is encapsulated within the container. The container environment also makes support easier as the entire environment can be recreated months or years later and reproduce the identical firmware download. They also claim that upgrading to newer SDK versions will be possible with a single command line. Silicon Labs developers usually must rebuild their entire application starting from a fresh sample application in a newer SDK to upgrade.
I have not had enough time using the Trident tools to make a full set of Tips and Tricks. I plan to implement Geographic Command Class V2 in both Silicon Labs and Trident in the coming months and will present more Tips in a future blog post.
Trident IoT Tips and Tricks:
- Use the latest version of elcap – elcap about
- elcap self doctor – checks your environment, execute this if something is not working
- The problem is you usually need to start the Docker Desktop application
- Append –help to any elcap command for more information
- Trident relies on the Segger Ozone Debugger
- VS Code integration with Ozone is expected in a future release
- elcap creates a Segger .jdebug file for Ozone as part of the build process
- In config.cmake set the following so Ozone finds all source code
- Set(ZWDSK_CONFIG_USE_SOURCES “ON”)
- Takes a little longer to compile but can single step ALL the code
- Turn it off again when close to release for faster compile times
- Use a Segger J-Link to debug your own PCB
- The connector pinout is NOT the same as the Silabs MiniSimplicity header
- The Trident devkit has a J-Link built in but does not debug external PCBs
- The DKR-HOST can be used to debug trident based PCBs
- The build environment is based on CMake
- To configure the project, edit:
- txt
- App/CMakeLists.txt
- Configuration will be simplified in a future release
- Complete reference firmware is available on request for several sensor types
- Start the PCC, Zniffer or Tridents own cross-platform Z-Wave/Zigbee Sniffer from elcap
- To configure the project, edit:
Sleep Debug
One of the most challenging debug tasks is ensuring the device sleeps when it is supposed to and is awake when needed. The key to debugging sleep is to have a good power supply sensing tool. Silicon Labs has the Advanced Energy Monitor (AEM) built into the WSTK development board and as a software tool in SSv6. The AEM with the newer WSTK2 (BRD4002) runs at 100kHz and has decent current range from microamps to 500mA. The key to any current sense tool is to also have a few digital logic channels to toggle GPIOs while also capturing the current. The industry standard tool for measuring current is from Joulescope and their JS220. Once you have one of these, you cannot debug a battery powered IoT device without one.
The screenshot above shows the power consumed by a ZG28 under various sleep conditions. Initially the current is under 3 microamps giving years of battery life. Then the hardware timer wakes the chip up to take a sensor reading and eventually transmits the data at +20dBm. Note the two digital signals at the bottom which help correlate exactly what the firmware is doing in various power consumption modes. The JS220 has four of these digital signals to identify what firmware is executing in which power mode. The 300Khz sample rate is 3X other tools which means you can see even short radio transmissions which other tools cannot measure. Below is a table of power sensing tools I’ve used. If you’ve got a favorite I have not seen before, let me know!
| Tool |
MSRP |
Specs | Comments |
| Joulescope JS220 |
$999 |
.5nA-3A
300kHz |
Industry leader but expensive |
| Silicon Labs AEM |
$179 |
100nA-495mA
100kHz |
Price is for a new WSTK2+ZG28 radio board
|
| Nordic PPK2 |
$99 |
200nA-1A
100kHz |
Price leader for a good tool
When current changes rapidly it struggles switching between shunt resistors and misses important spikes |
| TinyCurrent |
$75 |
1uA-2.5A
300kHz |
3 switch selectable shunts and opamp you connect to your oscilloscope |
| Oscilloscope Current Probes |
$1500+ |
10mA-15A
50MHz |
Current probes for oscilloscopes usually do not have sufficient resolution to measure microamp currents needed for Z-Wave sleep debug and are very expensive |
Next Steps
Part 5 of the Z-Wave Developer’s Journey discusses an often-overlooked schedule hit that in my view is absolutely critical, Firmware Hardening. Developers must keep in mind that IoT devices are often wired to mains power and may run for years without ever rebooting. Thus, the firmware must be resilient to account for impossible conditions that should never happen, but in the real world they often do. Remaining connected to the Z-Wave network and never “bricking” is critical to the success of your product and the reputation of Z-Wave. Do you have some Tips and Tricks to share? Please reach out to me directly via email.
About the Author
Eric Ryherd has been at the forefront of Z-Wave innovation since 2003, beginning as a consultant and later serving as a Field Application Engineer at Silicon Labs. Over the course of his career, he has contributed to the design and development of a wide range of Z-Wave products, including sensors, remote controls, motorized window shades, and in-wall dimmers, many of which are on the market today.
Although he “retired” in 2022, Eric remains deeply engaged in embedded systems and Z-Wave development through his blog, DrZWave.blog, and ongoing IoT consulting projects. He is also a familiar face at Z-Wave Alliance Unplug Fests, where he frequently serves as the lead coordinator, supporting interoperability and developer collaboration.
