RTCan missing frames

Wolfgang Grandegger wg at grandegger.com
Tue Feb 12 16:00:34 CET 2019


Hello Johannes,

Am 12.02.19 um 15:38 schrieb Johannes Holtz:
> 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 at 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

Why is "addr.can_ifindex = 24"? Something is broken in you build.

> 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.

I'm really puzzled what's going on. The CAN controller you use is well
supported.

Wolfgang.



More information about the Xenomai mailing list