Hello Wolfgang,

> ...
> >>> +         /* handle error on the bus */
> >>> +         lec_type = c_can_has_and_handle_berr(priv);
> >>> +         if (lec_type && (error_type != C_CAN_NO_ERROR))
> >>> +                 work_done += c_can_err(dev, error_type, lec_type);
> >>
> >> State changes are only reported if berr_reporting is enabled and a
> bus
> >> error occured. This needs to be fixed.
> >
> > As I mentioned earlier in a response to a review comment, the Bus
> Error
> > reporting for C_CAN seems different from sja1000 and flexcan
> approaches.
> > Do you think it will be useful to drop CAN_CTRLMODE_BERR_REPORTING
> from
> > priv->can.ctrlmode_supported as done by *pch* driver? Or do you have
> > a better idea..
> 
> You bus error reporting is OK. The problem is that it does not only
> affect bus errors but also state changes. State change messages should
> alway be send independent of priv->can.ctrlmode. It's just a matter of
> moving code to the right location. E.g. the code snippet above inside
> c_can_err() before you check for bus errors.
> 
> >> Feel free to send the output of "candump any,0:0,#FFFFFFFF" when
> >> sending
> >> messages without cable connected and with a bus error provocuted.
> >
> > OK. I will try to cross-compile candump for my arm-v7 architecture
> > and will send the output.
> 

I did some changes to the code to ensure that the state change and lec
handling are handled separately and properly.
Please find the candump any,0:0,#FFFFFFFF output below:

1. With No-Cable connected, I keep getting:
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME
  can0  20000004  [8] 00 28 00 00 00 00 00 00   ERRORFRAME

2. With Tx and Rx shorted to simulate bus-error, I get:
  can0  20000044  [8] 00 20 00 00 00 00 00 00   ERRORFRAME

In case 2, when I enable debug messages I get the correct state change sequence:
entered error warning state
entered error passive state
entered bus off state

Does this result seem fine to you?

Regards,
Bhupesh
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core

Reply via email to