Chris Verges wrote:
> Hi Wolfgang,
>
>> Has it worked with that board already in the past?
>
> Both good and bad news on this. The good news: at91_can.c has worked on
> an earlier rev of this board. The bad news: someone upgraded various
> components of the software around the same time we did a hardware rev,
> and I'm the first to start testing CAN with both the new software and
> new hardware. (No significant changes to the CAN traces on the
> hardware, however, so it's very low risk.)
>
> We're running Linux 2.6.28.10, patched with SocketCAN r1094 from SVN. I
> just re-patched from SocketCAN r1094 today to verify that we have the
> latest. (r1095 is now out, but it is a fix for slcan.c.)
>
> If I create a vcan0 interface, candump/cansend work just fine. Using
> can0 created by the at91_can.c driver does not work, resulting in the
> AERR messages.
>
> Unfortunately, we can't simply roll back to the earlier version of
> software due to upgrading our libc headers to v2.6.31. (Would using
> 2.6.31 libc headers with a 2.6.28 kernel cause problems? I can see
> about upgrading to 2.6.31 kernel if needed, but that's a bit o' work.)
>
> Any insights?
As I said, the ACK bus errors are a clear indication that the message
does not go out to the wire properly. I have an idea. When the device
is opened, the transceiver is switched on:
/*
* Switch transceiver on or off
*/
static void at91_transceiver_switch(const struct at91_priv *priv, int on)
{
if (priv->pdata && priv->pdata->transceiver_switch)
priv->pdata->transceiver_switch(on);
}
Does your platform code required a switch on and is it implemented
properly?
Wolfgang.
_______________________________________________
Socketcan-core mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-core
