If the lock tab has not been cut, this is expected behavior.
Hi
I used zymkey 4i in developper Mode, encrypt disk, perimeter detection… and all is ok
Now i try to activate Production Mode, I do actions
Turn off the power to the Pi.
Do not remove the battery.
Remove the zymkey from the Pi
Now Cut the Lock Tab
Replace the Zymkey onto the Pi and turn on power to the Pi
Close your perimeter circuit(s) (enclosure lid)
When i try to clear perimeters detection events , the function return -110
this is my code:
#include <zk_app_utils.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[]){
int num_timestamps = 0;
uint32_t *tab_event;
int rt;
printf("Test...\n");
zkCTX ctx;
if (zkOpen(&ctx)<0)
{
printf("Unable to setup RTC Module \n");
return 0;
}
rt=zkClearPerimeterDetectEvents(ctx);
printf("clearevts rt=%d ",rt);
return 0;
}
Can you help
Thanks
Error -110 is ETIMEDOUT “Connection timed out”. What is the LED on the zymkey doing at the time you issue the command?
Hi
The LED blink rapidly, and -110 occured in zkClearPerimeterDetectEvents(ctx) and zkOpen(&ctx) work fine
thanks
When i launch program, LED stop blinking then blink slowly , repeat this sequence sometime and after blink rapidly
What did you set your tamper detect policies to prior to clipping the tab? Had you ever set to self destruct?
Hi,
before clipping de tab, the policies was to notify. after cutting, i have this error . and one time i try to set policie to self destruct even i have error in clear events. i dont know if it was set really or not
thanks
Hi,
could you find the problem?
thanks
I don’t have an answer for you, because we haven’t been able to reproduce your issue yet. Maybe we should back up a little. If you don’t run your program, just boot up, what is the LED doing? Does it flash slowly, rapidly, or in some type of pattern? Did anything change on the host side from the time it was working in development mode to when you put it into production mode?
Hi,
Thank for your reply
I dont do any change when i put it into production mode.
below the sequence from the start:
1/ 7 sec sequence Normal
2/ 30 sec sequence Normal
3/ rapid 5 sec sequence
4/ slow 5 sec sequence
5/ rapid 5 sec sequence
6/ slow 5 sec sequence
7/ rapid 5 sec sequence
8/ 5 sec slow sequence
9/ …the rest is the same
Thanks
Hi,
Thank you for the reply. Could you post a video of the LED sequence?
Regards,
Bob
Hi,
That sequence is an indicator of an interruption in communication with the Zymkey. There are a couple of things we should rule out. The first would be your power supply. The recommended power for a PI 4 is at least 3A. A marginal power supply can cause all sorts of problems. The other thing that could lead to that LED sequence could be a conflict on the i2c bus, particularly with GPIO4 pin. Do you have any other devices that may use GPIO4, like the 1-Wire interface?
Bob
Hi,
The power supply is okey.
We use a separate power supply not USB charger, and its the same in developer Mode.
Yes we have a card connected to the same bus. But this card was already connected in the developer mode (before cutting the lock tab) and it worked well. You must draw your attention that now, the sd card is encrypted and that raspberry starts , decrypt the sd card, and I can connect normally to .
In the event that there is a conflict on the bus, how can we diagnose this point, so what to do to separate the I2C addresses and resolve the conflict because we have a board that shares the PIN 4 of the RPi.
knowing that now, the other card is operating normally.
Thanks
You can use an alternative GPIO pin for the Zymkey. The steps are outlined here:
https://community.zymbit.com/t/using-an-alternative-gpio-pin/589
Dear Bob,
when i try i2cdetect -y 1, i have this result
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: – -- – -- – -- – -- – -- – -- –
10: – -- – -- – -- – -- – -- – -- – -- – --
20: – -- – -- – -- – -- – -- – -- – -- – --
30: – -- – -- – -- – -- – -- – -- – -- – --
40: – -- – -- – -- – -- – -- – -- – -- – --
50: – -- – -- – -- – -- – -- – -- – -- – --
60: – -- – -- – -- – -- – -- – -- – -- – --
70: – -- – -- – -- – --
Its Normal? thats means nothing is detected?
thanks
It is normal. The i2c 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). Zymkey communicates to the host at a much more fundamental level, in part because the Zymkey protocol traffic is encrypted.
Hi Bob,
how do I know if there is actually a conflict with the other card. Knowing that both cards work anyway: zymkey can decrypt the disk and the other card also works normally.
I also point out that before cutting the tab, everything worked normally and nothing has changed since.
what do you suggest as next step?
thanks