For more troubleshooting help, see FAQ & Troubleshooting.
Q: Zymkey works intermittently, or fails to restart after cycling power.
A: Zymkey monitors the quality of 5V power coming into the host computer. If the voltage drops below a specified limit, even momentarily, then Zymkey will disable all security services to the host. This is a security feature to prevent powercycle and brown-own attacks. If you are powering a display, modem or other power hungry device from your Pi, then check the capacitiy and quality of your power supply. Learn more >
Q: Why is my Zymkey “invisible” to the i2c-tools suite?
A: Some people have become accustomed to using i2c-detect to do a first level check for correct installation and baseline functionality of i2c devices. However, these tools only really work if the i2c device communicates via a protocol that sits on top of i2c called SMBus or SMB (System Management Bus). Instead, Zymkey communicates to the host at a much more fundamental level, in part because the Zymkey protocol traffic is encrypted. While we’re on the topic, perhaps i2c-tools should have been called “smb-tools”? 
Q: Why does the LED continue to blink rapidly? It never blinks with the described pattern of once (in Development mode) or three times (in Production mode) every three seconds.
A: Check the following:
-
Make sure that you have enabled i2c support using raspi-config BEFORE your install the software. Also when you enable i2c communications be sure to follow the enable-disable-enable sequence.
-
If i2c support has been enabled correctly and the Zymkey LED is still rapidly blinking, check proper physical installation of the Zymkey as detailed in this “Getting Started” guide.
-
Check that the Raspberry Pi power is sufficient. The red LED on most Raspberry Pi models indicates if the Pi is being powered adequately. If it is not lit at all or flashes intermittently, try a different power supply or a different USB cable.
-
Zymkey uses GPIO header pins 3 and 5 for i2c communications and pin 7 as an interrupt signal to the Pi. Pin 7 should preferably be dedicated exclusively to Zymkey. Other devices may share the i2c bus with Zymkey, but there may still be address conflicts. By default, Zymkey uses slave address 0x30. If the address conflict cannot be resolved on the other i2c devices, there is a way of changing the i2c address on the Zymkey via the command line on the Pi (coming soon!). Using this application, the Zymkey address can be changed anywhere in the ranges of 0x30-0x37 or 0x60-0x67.
-
Oftentimes the 1-Wire interface relies on pin 7 (GPIO 4) for communication. If the 1-Wire interface is enabled, try disabling through raspi-config. If that resolves the problem take steps to either move the Zymkey interrupt signal from GPIO 4 or the 1-Wire interface from GPIO 4.
-
if the directory at /var/lib/zymbit or any of the files and/or subdirectories are corrupted or deleted, the Zymkey will fail to work.
IMPORTANT: if this happens when the Zymkey is locked (i.e. Production Mode), the Zymkey can never be used again.
Q: The LED blinks rapidly when booting, but eventually turns off. It doesn’t blink once or three times every 3 seconds as described.
A: This issue could be caused by the same issues described in the first question (Why does the LED continue to blink rapidly?). Additionally, this can be caused if a locked (Production Mode) Zymkey is moved to another Pi.
Q: If I cut the Lock-Tab on a Zymkey can I move that Zymkey to another Pi, or change the SD card ?
A: No. Cutting the Lock-Tab permanently binds that instance of Zymkey to the specific instances of host computer and SD card. This is a security feature to prevent credentials being moved from one host to another. DO NOT cut the Lock-Tab if you are still in development and expect to change the host or SD cards.
Q: When using the perimeter-detect feature, does the “self destruct” mode work (destroy all of its key material) even when the Lock Tab hasn’t been cut?
A: Self destruct mode works only after the Lock Tab has been cut._