Am 12.02.19 um 12:24 schrieb Wolfgang Grandegger:
Hello,
Am 12.02.19 um 11:42 schrieb Johannes Holtz:
Am 11.02.19 um 17:46 schrieb Wolfgang Grandegger:
... snip ...
UI suggest to write a simple test program to demonstrate the issue. It
should just open the socket and trying to receive messages... just the
necessary stuff. First with a blocking recv() and then non-blocking.
What hardware and software are you using (arch, board, linux, xenomai)?
?
Wolfgang.
The source code is attached:
compiled with -I/opt/xenomai/include -D_GNU_SOURCE -D_REENTRANT
-D__XENO__ -lrtdm -L/opt/xenomai/lib -lxenomai -lpthread -lrt -lnative
can frames sent by rtcansend
Test 1: blocking:
ID:0 DLC:2hex: 81 00 <-- NMT request
ID:709 DLC:1hex: 00 <-- answer node #9
ID:708 DLC:1hex: 00 <-- answer node #8
ID:703 DLC:1hex: 00 <-- answer node #3
ID:705 DLC:0hex: <-- here it gets weird ! DLC == 0
ID:70400 DLC:1hex: 01
ID:70600 DLC:1hex: 01
ID:70100 DLC:1hex: 01
ID:70200 DLC:1hex: 01
ID:1010000 DLC:1hex: 08
This means that you can receive messages from the CAN bus.
ID:53220 DLC:124 out of bounds. abort.
But that's wired.
Test 2: non blocking:
ID:0 DLC:2hex: 81 00 <-- NMT request
ID:709 DLC:1hex: 00 <-- answer node #9
ID:708 DLC:1hex: 00 <-- answer node #8
ID:703 DLC:1hex: 00 <-- answer node #3
ID:705 DLC:0hex: <-- same issue DLC is 0
ID:70600 DLC:1hex: 01
ID:70400 DLC:1hex: 01
ID:70200 DLC:1hex: 01
ID:70100 DLC:1hex: 01
ID:1010000 DLC:1hex: 08
ID:53220 DLC:124 out of bounds. abort.
Looks identical.
Also, I found another possible error source and I don't know if this
error picture would corresponds to this.
However, While reviewing all settings, I noticed that I made a mistake
with the RXBUF_SIZE which is set to 8096 instead of 8192. Must have been
asleep when writing this. I'm going to rebuild this module.
Let's try to understand why rt_dev_recv() does return bogus dlc.
What hardware and software are you using (arch, board, can controlelr,
linux, xenomai)?
Wolfgang.
I modified the program a little to send it's own requests via one single
socket. The output look like this.
send succeeded
ID:708 DLC:1hex: 00
ID:709 DLC:1hex: 00
ID:703 DLC:1hex: 00
ID:706 DLC:1hex: 00
ID:705 DLC:7hex: 00 00 01 01 00 09 07
send succeeded
send succeeded
send succeeded
send succeeded
send succeeded
And a parallel rtcanrecv output like this:
root@machinectrl:~# rtcanrecv rtcan0
#0: (1) <0x000> [2] 81 00
#1: (1) <0x708> [1] 00
#2: (1) <0x709> [1] 00
#3: (1) <0x703> [1] 00
#4: (0) <0x706> [0]
#5: (0) <0x500> [1] 01
#6: (0) <0x400> [1] 01
#7: (0) <0x100> [1] 01
#8: (0) <0x200> [1] 01
#9: (0) <0x000> [1] 08
#10: (24) <0x220> [124] 00 00 82 00 00 00 01 08 01 00 00 00 f0 84 04 08
00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00 c0 06 60 b7 18 68 91 bf
78 69 91 bf 80 0d 7c b7 ce 68 91 bf c0 68 91 bf 00 9b 04 08 60 69 91 bf
78 69 91 bf cf 8e 04 08 00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00
00 00 00 00 68 00 0f c1 e0 b8 7a b7 00 00 00 00 01 00 00 00 30 ae 10 f7
04 5e 60 b7 e0 68 91 bf b0 68 91 bf
#11: (24) <0x220> [124] 00 00 05 07 00 00 01 07 01 00 00 00 f0 84 04 08
00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00 c0 06 60 b7 18 68 91 bf
78 69 91 bf 80 0d 7c b7 ce 68 91 bf c0 68 91 bf 00 9b 04 08 60 69 91 bf
78 69 91 bf cf 8e 04 08 00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00
00 00 00 00 68 00 0f c1 e0 b8 7a b7 00 00 00 00 01 00 00 00 30 ae 10 f7
04 5e 60 b7 e0 68 91 bf b0 68 91 bf
#12: (32) <0x000> [50] 05 05 07 00 00 01 07 00 01 00 00 00 f0 84 04 08
00 af 04 08 c0 68 91 bf 00 00 00 00 00 00 00 00 c0 06 60 b7 18 68 91 bf
78 69 91 bf 80 0d 7c b7 ce 68
#13: (9) <0x100> [7] 05 07 00 00 01 07 00
#14: (0) <0x100> [0]
#15: (1) <0x705> [7] 00 00 01 01 00 09 07
None of this makes sense to me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: can_recv.c
Type: text/x-csrc
Size: 7066 bytes
Desc: not available
URL:
<http://xenomai.org/pipermail/xenomai/attachments/20190212/e57ccd89/attachment.c>
