Lpc2000

--- In lpc2000@yahoogroups.com, "alipowsky" <a.lipowsky@g...> wrote:
> > Two questions:
> > 
> > 1) Does "leading 12 bits" mean the first 12 bits transmitted?
These
> are the 
> > most significant bits in the message Id right?
> Yes thats what we found, and probably zthat the reason why the bug
> only happens to occur with 29 Bit Identifiers. 
> 
> > 2) So does this mean that if there is a difference in this area,
> then the 
> > arbitration will be OK?
> In our tests, we did not get this faults when there was a difference
> in this area (first 12 Bits).
> > 
>  
> > This will likely break many/most J1939 or SAE11785 systems which
> will often 
> > only have differences in the last (lsb) 16 bits.
> 
> That's right and that really makes the can controller useless in
such
> kind of applications.
> 
> When we reported this problem to Philips the german Philips FAE told
> us that there was a known problem in this area, but their report did
> not mention corrupted messages but totally lost messages.
> May be, their setup had an accepptance filter setting which catched
> the corrupted frames.
> Nevertheless i found it very disappointing, that Philips obviously
> does not report all know problems to the customers.
> By the way the actual errata sheet on the web still does not
mention 
> this kind of problem.

To improve the happiness about the LPC2XXX CAN-Controller, we have
another problem:
Sometimes, but very rarely the controller transmits 29bit messages
corrupt. Only some of the first 11bit are wrong. The remaining bits of
the identifier and the data bytes are correct, and the CAN - CRC is
generated accordingly. 

This problem occurred until now about 8 times between millions of
correct CAN-frames.
It seams to happen, if there is a lot of traffic on the busses. In our
system a LPC2294 has to work with 4 busses, 3 of them with 1 MBaud and
traffic up to 80%.