ZWP500
™
Z-Wave Production Programmer & Tester
www.ExpressControls.com
February 2018
Bringing
the Internet of Things (IoT) to Life
14
Programmer Example Python Application
The ZWP500 is primary a tool for programming the firmware into each 500 series DUT during production. The firmware
hex file is downloaded into the ZWP500 and then a simple short command is used to apply the proper VIO voltage for
programming, enter programming mode on the DUT, save the NVR values, erase FLASH, restore the NVR and update
with the desired values, transfer the firmware to the DUT and finally check the CRC of the firmware to verify the process is
100% accurate. If the NVR is identified as being uncalibrated, a calibration step can be performed using the 1ppm
accurate crystal of the ZWP500. See the SensorPIR example for more details.
Product Validation
Product Validation Example Python Application
TBD
Production Testing
Product testing is a short, focused test that identifies manufacturing defects in each DUT. Time is money on the
production floor so the test is usually a few tens of seconds long. The goal is to ensure any opens, shorts, missing or
defective components are identified so the DUT can be reworked. Ideally each customer receives a fully functional DUT
with a minimal number of returns.
Production Testing Example Python Application
The SensorPIR example code contains a short example of a test program where the VIO current to the DUT is measured
and several pins are toggled to verify it is defect free.
Manufacturing Data Logging
The SensorPIR example also logs a number of metrics into a comma separated value (.csv) file. Each DUT tested is
recorded in the file for later analysis and identification of areas of yield improvement.
ZWP500 Interface
The RPi communicates to the ZWP500 PSoC5 board via a UART which runs at 921600 baud. The following sections
detail the commands that can be sent to the PSoC5 and their responses. It is recommended to use the sample application
as a guide for the typical usage the low-level PSoC5 commands. The sample applications are in Python but any
programming language such as C can be used. All communication is in ASCII making it easier to debug.
PSoC Commands
The PSoC processor receives commands from the RPi over the UART. Each command is typically an ASCII string and
some optional data followed by a <CR>.
See the section “Terminal Window Settings with PuTTY” for more details on how
to setup a terminal window to interact with the PSoC directly. Normally a Python or C program is used to communicate
with the PSoC. While the commands can be entered manually this is mostly just for debug purposes. The full command
name must be sent and the capitalization must exactly match as shown. The end of line character <LF> is ignored as are
spaces and the TAB character. Every command is echoed allowing the program to check that the command has been
properly received.
Every command responds with one of the following acknowledgements:
* = Command accepted
? = Command not understood - usually caused by an invalid command or corrupted data
# = Command discarded - usually because some other process is currently running
! = Command failed - additional data is typically provided with the reason for the failure
Many commands return additional data after the acknowledgement.
