I could again capture a case where some (false) 16 byte MTU frames were received - attached.
Loop 24435 2023-01-04T14:25:57 last+4s total:28h36m
.....
+ ./sctestself -b -n 4 -l 999 -t 2 -v cmperr,logmsg -F refilldata,leastdots,allowintloopb,stoponerror -X 192.168.5.221:4001 -d 24 can0
CAN selftest can0 Wrong-RX16(rxcnt=0):000#
Wrong-RX16(rxcnt=1):000#
Wrong-RX16(rxcnt=2):000#
Wrong-RX16(rxcnt=3):000#
idx 0 tx:2A5#00 00 DB 83 C7 C6 D2 22 D0 F1 81 25 26 15 EF 1F 1C 6F 91 BC 00 DC EF 74
rx:000#
idx 1 tx:2A5#00 01 B2 FA 3F 38 59 F9 13 11 4D EE 94 14 B4 67 36 84 58 B7 A9 7F CC 99
rx:000#
idx 2 tx:2A5#00 02 9E E9 08 2F A5 08 0C 95 7C BE 8F BB F7 E8 B5 0A F9 02 F8 8E 16 AC
rx:000#
idx 3 tx:2A5#00 03 F5 4D 30 4D 04 DA CC D1 73 6B BA 7B 9A 5F 84 A6 F4 00 65 83 BC 5C
rx:000#
.c (0) fail
0: RX16 (004/003) 000#
0: RX16 (004/002) 000#
0: TX72 (003/002) 2A5#00 03 F5 4D 30 4D 04 DA CC D1 73 6B BA 7B 9A 5F 84 A6 F4 00 65 83 BC 5C
0: RX16 (003/001) 000#
0: TX72 (002/001) 2A5#00 02 9E E9 08 2F A5 08 0C 95 7C BE 8F BB F7 E8 B5 0A F9 02 F8 8E 16 AC
0: RX16 (002/000) 000#
0: TX72 (001/000) 2A5#00 01 B2 FA 3F 38 59 F9 13 11 4D EE 94 14 B4 67 36 84 58 B7 A9 7F CC 99
0: TX72 (000/000) 2A5#00 00 DB 83 C7 C6 D2 22 D0 F1 81 25 26 15 EF 1F 1C 6F 91 BC 00 DC EF 74
External logger data:
(54:40.690.506 +0.089) RX B - 2A5 [24] 00 03 F5 4D 30 4D 04 DA CC D1 73 6B BA 7B 9A 5F 84 A6 F4 00 65 83 BC 5C
(54:40.690.417 +3.307) RX B - 2A5 [24] 00 02 9E E9 08 2F A5 08 0C 95 7C BE 8F BB F7 E8 B5 0A F9 02 F8 8E 16 AC **** suspicious delay
(54:40.687.110 +0.088) RX B - 2A5 [24] 00 01 B2 FA 3F 38 59 F9 13 11 4D EE 94 14 B4 67 36 84 58 B7 A9 7F CC 99
(54:40.687.022 +26.681) RX B - 2A5 [24] 00 00 DB 83 C7 C6 D2 22 D0 F1 81 25 26 15 EF 1F 1C 6F 91 BC 00 DC EF 74 **** plausible delay
(54:40.660.341 +0.071) RX B - 2A5 [16] 00 03 95 89 EA 22 98 62 36 77 C2 F9 69 99 0D 32
(54:40.660.270 +0.417) RX B - 2A5 [16] 00 02 CF 52 6C 29 E2 86 73 10 3E 93 D4 72 30 05
(54:40.659.853 +0.071) RX B - 2A5 [16] 00 01 8D 0E 77 13 DF 60 C3 F1 D7 14 C9 8B CC 04
(54:40.659.782 +0.460) RX B - 2A5 [16] 00 00 5A 90 19 49 2D B8 20 C4 34 9D 31 23 59 E5
(54:40.659.322 +0.070) RX B - 2A5 [16] 00 03 86 D1 E9 AF 12 76 51 D7 B4 B8 3B 43 85 68
(54:40.659.252 +0.420) RX B - 2A5 [16] 00 02 EF 9D 9F D6 97 7B 7D 6C EF BB B4 6A B5 92
My sctestself received four 000# frames and quits. There are more such frames in the candump. None of them
were received by the external logger and neither in my own send-log.
It seems this happens when the sctestself does it's first test loop - which I also have seen in a second
case. The 26.681 ms delay seems to be normal as the program is started by the outer test loop.
The +3.307 ms delay however is not normally seen when sctestself does it's first loop, not even
if I drop caches after each sctestself run.
Can sctestself do something wrong to cause it?
-- Stefan
Attachment:
20230104T1425_can0_rx16.tgz
Description: 20230104T1425_can0_rx16.tgz
