I’ve just moved a ZymKey still in developer mode from one Pi to another (both running Buster). It did go into slow blinking mode on the old Pi about 6 weeks ago. The new Pi has the latest Buster fully updated, i2c enabled. On installing the software no errors are reported and it gets through to ‘Rebooting now…’.
This is on a Pi3B+ with official 5.1V 2.5A psu. Keyboard, mouse and hdmi monitor connected.
However the ZymKey remains in its rapidly blinking mode?
I’ve tried this on 3 fresh installs with the same result. Some info below - anything else that I can check?
date
Wed 8 Apr 15:21:49 BST 2020
sudo apt update
Hit:1 http://archive.raspberrypi.org/debian buster InRelease
Hit:2 http://raspbian.raspberrypi.org/raspbian buster InRelease
Hit:3 https://zk-sw-repo.s3.amazonaws.com/apt-repo-buster buster InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
sudo apt full-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Release: 10
Codename: buster
uname -a
Linux raspberrypi 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux
cat /var/log/syslog | grep Booting Linux|zkifc|Zymkey
Apr 8 08:30:21 raspberrypi kernel: [ 0.000000] Booting Linux on physical CPU 0x0
Apr 8 08:36:37 raspberrypi systemd[1]: Starting Zymkey Interface Connector...
Apr 8 08:36:37 raspberrypi systemd[1]: Started Zymkey Interface Connector.
Apr 8 08:36:37 raspberrypi zkifc[2641]: /usr/bin/zkifc: error while loading shared libraries: libzk.so: cannot open shared object file: No such file or directory
Apr 8 08:36:37 raspberrypi systemd[1]: zkifc.service: Main process exited, code=exited, status=127/n/a
Apr 8 08:36:37 raspberrypi systemd[1]: zkifc.service: Failed with result 'exit-code'.
Apr 8 08:36:47 raspberrypi systemd[1]: zkifc.service: Service RestartSec=10s expired, scheduling restart.
Apr 8 08:36:47 raspberrypi systemd[1]: zkifc.service: Scheduled restart job, restart counter is at 1.
Apr 8 08:36:47 raspberrypi systemd[1]: Stopped Zymkey Interface Connector.
Apr 8 08:36:47 raspberrypi systemd[1]: Starting Zymkey Interface Connector...
Apr 8 08:36:48 raspberrypi systemd[1]: Started Zymkey Interface Connector.
Apr 8 08:38:10 raspberrypi systemd[1]: Stopping Zymkey Interface Connector...
Apr 8 08:38:28 raspberrypi zkifc[2830]: Zymkey Interface Connector, version 00.08.01 Mar 31 2019 21:34:00
Apr 8 08:38:29 raspberrypi systemd[1]: zkifc.service: Succeeded.
Apr 8 08:38:29 raspberrypi systemd[1]: Stopped Zymkey Interface Connector.
Apr 8 08:38:29 raspberrypi systemd[1]: Starting Zymkey Interface Connector...
Apr 8 08:38:30 raspberrypi systemd[1]: Started Zymkey Interface Connector.
Apr 8 08:38:40 raspberrypi systemd[1]: Stopping Zymkey Interface Connector...
Apr 8 08:39:19 raspberrypi zkifc[2905]: Zymkey Interface Connector, version 00.08.01 Mar 31 2019 21:34:00
Apr 8 08:39:20 raspberrypi systemd[1]: zkifc.service: Succeeded.
Apr 8 08:39:20 raspberrypi systemd[1]: Stopped Zymkey Interface Connector.
Apr 8 08:39:25 raspberrypi kernel: [ 0.000000] Booting Linux on physical CPU 0x0
Apr 8 08:39:32 raspberrypi systemd[1]: Starting Restore System Clock from Zymkey...
Apr 8 08:44:33 raspberrypi systemd[1]: Started Restore System Clock from Zymkey.
Apr 8 08:44:33 raspberrypi systemd[1]: Starting Zymkey Interface Connector...
Apr 8 08:44:33 raspberrypi systemd[1]: Started Zymkey Interface Connector.
pi@raspberrypi:~ $
It sounds like you have tried to migrate an existing SD card and Zymkey from an RPi 2 to an RPi 3B+. I’ve completed such a test and it worked with no problem.
Here’s the scenario I worked out:
Configure an RPi 2 with a Zymkey.
Install Buster desktop (Feb 13, 2020) on RPi 2 with a Zymkey. On first boot, this version of Buster upgrades itself to the latest version.
Enable i2c with raspi-config.
Install Zymbit software. System reboots itself.
After reboot, check that Zymkey flashes once per 3 seconds.
Migrate SD card and Zymkey from original RPi 2 to an RPi 3B+ and power on.
This sounds like your RPi 3B+ might have a problem with the i2c pins (pins 3 & 5) or GPIO4 (pin 7). Have you tried this on another RPi 3B+?
To answer your other question, if there is an error experienced at the Zymkey, it should flash an error code. This looks like the following sequence:
Very fast blinking for about 1 second (around 8 - 10 flashes per second)
No blinking for about 1 second
Slow blinks (around 2 per second). The number of times this blinks represents the error code.
This sequence repeats 3 times and then should return to the “waiting for host connection” flashing pattern (about 4 times per second).
If all you see is the “waiting for host connection” flash pattern, there might be something wrong with the i2c pins. If you see an error code sequence of 8 flashes, there is probably something wrong with GPIO4.
My guess is that the Zymkey software cannot cover the new hardware rpi4 and Buster 10. Thanks for clarity on this point from the manufacturer. I would like to know if I have to use another product or if there is a solution for this in the near future. Thanks to the great developers. For me some functions are still missing in version 4…
All of the functions you highlight are in our next release of product (Hardware and software). This is not public information at this time, but if you care to send us an email - support@zymbit.com, then perhaps we can open a private dialogue to discuss your needs.
We have tested the RPi4 with the latest Buster and it works. I sent this to you via email but I’ll repost the questions here so the rest of the community can see. Hopefully we can determine what’s different between the working and non-working configurations.
It is IMPORTANT you have a good power supply. The RPi4 requires at least 3 Amps, and with a HAT and video displays, even more power would be better. Can you confirm the output of your power supply?
Is this a new setup for you, or is it something that previously worked and stopped working after something changed? Do you just have one Zymkey and one RPi4, or do you have the ability to switch hardware to see if there may be some bad hardware?
Have the GPIO pins ever been used for anything else? In particular, the 1-Wire interface should be disabled. You can do that through raspi-config -> Interfacing Options -> 1-Wire -> Disable. If you aren’t sure, send me a copy of your /boot/config.txt and I can take a look.
I don’t think it should matter, but are you using Raspian Desktop, Raspian Lite, or Raspian Full? The image date we tested with is 2020-02-13, plus apt-get update, apt-get upgrade.
Thanks it works with a clean image!
The PSU are more then 3A i know rpi4 needs ampere
The RTC Clock not works. Status out:
Local time: Sat 2020-05-16 06:01:17 BST
Universal time: Sat 2020-05-16 05:01:17 UTC
RTC time: n/a
Time zone: Europe/London (BST, +0100)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
The Time sync by reboot without nic runs. Date is correctly
That is great news that it is working. It sounds like the RTC is setting your date correctly, which is also good news. The RTC won’t show up in the timedatectl display, or hwclock. Here’s a little background copied from another post:
Given that Raspbian and friends are a moving target, we elected to not develop any kernel modules for the RTC and, therefore, the stock Linux components (e.g. hwclock) won’t work with Zymkey’s RTC.
Instead, our approach was to keep everything in user space and in systemd. During boot, we currently have a systemd script that checks zymkey for a more recent time than the last one that RPi captured and stored on disk during the last proper shutdown.
This means that, if everything is properly configured and running, the system time (GMT) should be initially set to zymkey’s time before NTP has had a chance to run.
