RTCan missing frames

Johannes Holtz johannes.holtz at compador.de
Wed Feb 13 10:37:05 CET 2019


Am 12.02.19 um 18:53 schrieb Wolfgang Grandegger:
> Am 12.02.19 um 18:24 schrieb Johannes Holtz:
>> Am 12.02.19 um 18:05 schrieb Wolfgang Grandegger:
>>> Am 12.02.19 um 16:19 schrieb Johannes Holtz:
>>>> Am 12.02.19 um 16:00 schrieb Wolfgang Grandegger:
>>>>> 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.
>>>> In the xenomai build? how do I find out what? it all compiled well.
>>>>
>>>> I patched the driver  before building tkernel with
>>>> 0001-rtcan-ems_pci-driver-update-to-support-more-devices.patch.gz
>>> Can you show me that patch.
>> See attachment.
>>>> I used the ipipe patch from the stable release,
>>>>
>>>> and then build it normally.
>>>>
>>>> Might the RX buf size that I changed a problem?
>>> What exactly did you change? I think "rtcanrecv" does not use it.
>>>
>>> Wolfgang
>> The kernel option CONFIG_XENO_DRIVERS_CAN_RXBUF_SIZE I at first I set it
>> to a wrong value  8096 but eve after I changed it to 8192 it didnt
>> change anythingand now i set it back to 1024 with no improvement either.
> Ah, a value of 8096 does make trouble, e.g. with expression like the
> following:
>
>          sock->recv_tail = (sock->recv_tail + cpy_size) &
>              (RTCAN_RXBUF_SIZE - 1);
>
> Could you please make a *clean* rebuild from scratch with a value 2^N,
> either 8192 or 1024.
>
> Wolfgang.

Building the complete Kernel anew did the trick. Don't really understand 
why re-building (and installing) just the module didn't work.

Anyway, I'm happy that it works now. So, as a takeaway: Don't mess with 
the CAN_RXBUF_SIZE.

Cheers and thank you Wolfgang. Schoenen Tag noch.

Johannes





More information about the Xenomai mailing list