Page 1 of 2
piSerial prints wrong information
Posted: 20 Oct 2020, 18:34
by yazev
Hello!
I've noticed that sometimes piSerial prints wrong data. After multiple subsequent calls with correct output it may print values that are slightly different from expected. In my tests when I'm performing 10000 and may get 100 correct reads and then 1 or 2 identical, but incorrect, and then it switches back to printing correct values. This cycle repeats. Out of 10000 calls 2% return incorrect data. Tested on 3 RevPi Connect+ and with freshly flashed image.
Could you please help me to resolve this issue? I'm heavily relying on serial numbers and crypto chip in my project.
Re: piSerial prints wrong information
Posted: 26 Oct 2020, 16:36
by dirk
Hi yazev, thank you for your report. I could reproduce it with the following code:
Code: Select all
#!/bin/bash
# https://revolution.kunbus.de/forum/viewtopic.php?f=6&t=2466
N=0
X=$(piSerial)
echo 'test output of "piSerial"'
while true; do
Y=$(piSerial)
let "N = $N + 1"
if [ "$X" != "$Y" ]; then
echo "Wrong at $N : [ $X ] [ $Y ]"
fi
done
Re: piSerial prints wrong information
Posted: 16 Nov 2020, 17:20
by dirk
Hi the problem is fixed. The pull request can be found here:
https://github.com/RevolutionPi/piSerial/pull/14
Re: piSerial prints wrong information
Posted: 23 Nov 2020, 09:39
by dirk
Hi sorry this is link leeds to an internal repository unfortunately. So it will be fixed by the next release.
Re: piSerial prints wrong information
Posted: 21 Jan 2021, 14:17
by jenskastensson
Hi I think I have the same problem, however it is very frequent.
Can you please confirm that this is the same problem and that there's a fix available soon ? (sudo apt update -all packages are up to date)
For now, we cannot ship any revpi devices at all !
test output of "piSerial"
Wrong at 36 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 JJTU3FCE53 nmwone ]
Wrong at 37 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 JJTU3FCE53 lr22vf ]
Wrong at 73 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 JJTU3FCE53 nmwone ]
Wrong at 74 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 JJTU3FCE53 nmwone ]
Wrong at 111 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 JJTU3FCE53 nmwone ]
Wrong at 112 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 VK45DGQGUA lr22vf ]
Wrong at 148 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 JJTU3FCE53 nmwone ]
Wrong at 149 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 JJTU3FCE53 nmwone ]
Wrong at 186 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 JJTU3FCE53 nmwone ]
Wrong at 187 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 JJTU3FCE53 nmwone ]
Wrong at 264 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 JJTU3FCE53 nmwone ]
Wrong at 265 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 JJTU3FCE53 lr22vf ]
Wrong at 301 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0123E01004050607 P8ZKJJYXWX h92one ]
Wrong at 302 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 JJTU3FCE53 nmwone ]
Wrong at 339 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 JJTU3FCE53 nmwone ]
Wrong at 340 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 JJTU3FCE53 nmwone ]
Wrong at 377 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 JJTU3FCE53 nmwone ]
Wrong at 378 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 JJTU3FCE53 nmwone ]
Wrong at 396 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0123E0107E6B6B18 4NWHJGRKZU lrlacp ]
Wrong at 418 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0123E0107E6B6B18 4J1ZHWKZXR lr2xvf ]
Wrong at 535 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 JJTU3FCE53 nmwone ]
Wrong at 536 : [ 0123E0107E6B6B18 VK45DGQGUA lr22vf ] [ 0001020304050607 JJTU3FCE53 nmwone ]
Here's the output from a terminal approximately a new command every 5 sec
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0001020304050607
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0001020304050607
pi@RevPi46529:~ $ piSerial -s
0001020304050607
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0001020304050607
pi@RevPi46529:~ $ piSerial -s
0001020304050607
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0001020304050607
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0001020304050607
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0001020304050607
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0001020304050607
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0001020304050607
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0001020304050607
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0001020304050607
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0001020304050607
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0001020304050607
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
pi@RevPi46529:~ $ piSerial -s
0123E0107E6B6B18
Re: piSerial prints wrong information
Posted: 26 Jan 2021, 16:31
by dirk
Hello jenskastensson, thank you for your patience. The piSerial issue is under evaluation by the RevPi development team. I hope that we will find a quick solution here.
Re: piSerial prints wrong information
Posted: 26 Jan 2021, 23:45
by h2oil
Having same issue, when is the new release due?
Its causing problems with our current DAQ project.
Re: piSerial prints wrong information
Posted: 27 Jan 2021, 14:47
by dirk
Hi h2oil, we are on it and we are aware of the urgency. We are already discussing options here and want to deliver a solution the fastest possible way. Thank you for your patience.
Re: piSerial prints wrong information
Posted: 29 Jan 2021, 15:15
by dirk
Hello everyone, thanks for your patience There is good news a fix is created.
You can install the new version as follows:
However, an error may occur if you call it repeatedly:
The program also returns an error code. With the next call it should work again.
These errors result from the fact that the chip sometimes goes to sleep.
So if you handle this error there should be no more showstopper.
Re: piSerial prints wrong information
Posted: 30 Jan 2021, 15:51
by jenskastensson
Hello Dirk and many thanks for the update and the solution !
I would like to ask for some additional information to understand what we need to change on our side.
1. Can you elaborate this statement "However, an error may occur if you call it repeatedly:"
Does this mean that the first call is most likely fine but subsequent calls may fail ?
This first statement can be understood to be in conflict with the statement "chip sometimes goes to sleep" - waking up a sleeping chip would rather fail the first call and not subsequent calls.
2. Another question: Will this SW release have any impact on older hardware already released (working without any issue). Do we need to take any action ?
3. Related question: is it possible to detect in run-time directly or indirectly if the chip 'suffers' from this problem ?
4. Is it possible to force/simulate the error message (for test)?
5. Can you describe the typical behavior of the sleep mode: after how long time of inactivity does the chip enter sleep mode. Will the chip typically be awake after reboot for a certain time?
We would really appreciate more details and explanations, so we can better understand the impact on our software !
Best regards
Jens