Hello Oliver, [snip..] > > > > 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. Regards, Bhupesh _______________________________________________ Socketcan-core mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-core
