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. 

I've confirmed this too. Due to my network structure I can get an 
error approx once every 2.5 sec with very low bus loading (~20 
frames/sec).
> 
> > 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.


I figured out a way that seems to fix the problem in J1939.

In J1939 the source and destination addresses are in the least 
significant bits which means that they will not work for arbitration 
purposes on the Philips CAN device due to this bug.

However, the J1939 priority field is in the first (most significant)  
12 bits. We can then force a difference in the 12 bits by using a 
different priority for the Philips device. Luckily in my system there 
are 4 nodes, but only one is a Philips. The Philips will run at one 
priority and the other nodes at a different priority.

This isn't very nice, but it means we can make the system reliable 
again.