Hi,
> > > I have been debugging a case of random loss of certain CAN frames
> at
> > the RX end,
> > > when I use the c_can driver.
> > >
> > > I use a fairly simple setup:
> > > ~ For TX, I use a vector CANAnalyzer tool (which can generate CAN
> > frames
> > > with high bus load)
> > > ~ At RX end I use my board which has a bosch c_can core and use
> > the
> > > `candump` application to dump all the frames arriving on the CAN
> > interface.
> > > ~ For testing I compare the sent frames with the frames received
> > by candump.
> >
> > Hello Bhupesh,
> >
> > the first interesting thing would be to check whether the frames are
> > dropped
> > on socketlayer (due to a slow processing in userspace) or somewhere
> in
> > the driver.
> >
> > Please run the candump with the '-d' option, that enables the
> > dropcounter in
> > the socket receive path.
> >
> > See details here:
> > https://lists.berlios.de/pipermail/socketcan-users/2010-
> > January/001226.html
> >
> > If it's not on the socketlayer it's worth checking the driver ;-)
> >
>
> Ok. I was a bit late in doing some tests.
> Actually I was stuck in getting the latest `candump` version cross
> compiled for
> my ARM platform. I was getting some errors with `useconds_t` being
> undefined.
>
> However, I did some ugly hacks and now I can run candump with -d
> option.
> I see the DROPCOUNT messages like this:
> DROPCOUNT: dropped 1 CAN frame on 'can0' socket (total drops 1)
>
> Pardon my limited knowledge on this option, but how can I determine
> whether
> this packet was dropped by the driver or the user-space application.
>
Forgot to add the `ip -d -s link show can0` output:
2: can0: <NOARP,UP,LOWER_UP,ECHO> mtu 16 qdisc pfifo_fast state UNKNOWN qlen 10
link/can
can state ERROR-ACTIVE restart-ms 0
bitrate 988095 sample-point 0.750
tq 253 prop-seg 1 phase-seg1 1 phase-seg2 1 sjw 1
c_can: tseg1 2..16 tseg2 1..8 sjw 1..4 brp 1..1024 brp-inc 1
clock 83000000
re-started bus-errors arbit-lost error-warn error-pass bus-off
0 0 0 0 0 0
RX: bytes packets errors dropped overrun mcast
1380496 172562 0 0 0 0
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
I can decipher from this dump that the packet dropped and errors
is 0 while DROPCOUNT messages are still present in `candump -d` output.
Any idea, where there frames are being dropped?
Regards,
Bhupesh
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
