Lpc2000

As we spent a lot of time and work in isolating and reporting the
following bug, we want to make this information available to all, who
intend to use the CAN-Controller of the LPC2119 or LPC2292 or other
LPC2XXX derivate.

If you use 29 Bit identifier, it can happen that the unit will change
content of a received data frame. Identifier and data byte are
suspected to be corrupted.

This happens, if the unit looses arbitration to another Can-Node.
Normally the CAn-Controller will switch over to reception, if he had
lost arbitration and will receive the message of the other node,
delaying his own message.

On the actual LPC-CAN-derivates the same happens, but the message,
which is received in this case, will not contain the data from the
message, which won the arbitration, but it will contain arbitrary
Identifier and data bytes.

This happens using 29 Bit identifiers, and if the identifier of the
messages in the arbitration battle, have the same leading 12 bits.
 

We reported this bug to philips on 25.4.2005 and got a confirmation in
the meantime.
Finaly we don't understand, why this important information is not made
available in the corresponding errata sheets by philips.

Hi,

will we receive this invalid message in any case or only if its (arbitrary)
identifier matches our acceptance filters?

To Philips: When will this misbehaviour be eliminated?

Peter




-----Ursprüngliche Nachricht-----
Von: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] Im Auftrag von alipowsky
Gesendet: Donnerstag, 19. Mai 2005 11:34
An: lpc2000@yahoogroups.com
Betreff: [lpc2000] Severe Bug in LPC2XXX CAN-Controller

As we spent a lot of time and work in isolating and reporting the
following bug, we want to make this information available to all, who
intend to use the CAN-Controller of the LPC2119 or LPC2292 or other
LPC2XXX derivate.

If you use 29 Bit identifier, it can happen that the unit will change
content of a received data frame. Identifier and data byte are
suspected to be corrupted.

This happens, if the unit looses arbitration to another Can-Node.
Normally the CAn-Controller will switch over to reception, if he had
lost arbitration and will receive the message of the other node,
delaying his own message.

On the actual LPC-CAN-derivates the same happens, but the message,
which is received in this case, will not contain the data from the
message, which won the arbitration, but it will contain arbitrary
Identifier and data bytes.

This happens using 29 Bit identifiers, and if the identifier of the
messages in the arbitration battle, have the same leading 12 bits.
 

We reported this bug to philips on 25.4.2005 and got a confirmation in
the meantime.
Finaly we don't understand, why this important information is not made
available in the corresponding errata sheets by philips.
  




 
Yahoo! Groups Links

This indeed sounds like a severe bug that will impact us.  Anyone 
else experience this behavior?  Philips apps?
James

--- In lpc2000@yahoogroups.com, "JUPE Peter Jungreuthmayer" 
<jupe@d...> wrote:
> 
> Hi,
> 
> will we receive this invalid message in any case or only if its 
(arbitrary)
> identifier matches our acceptance filters?
> 
> To Philips: When will this misbehaviour be eliminated?
> 
> Peter
> 
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] Im 
Auftrag von alipowsky
> Gesendet: Donnerstag, 19. Mai 2005 11:34
> An: lpc2000@yahoogroups.com
> Betreff: [lpc2000] Severe Bug in LPC2XXX CAN-Controller
> 
> As we spent a lot of time and work in isolating and reporting the
> following bug, we want to make this information available to all, 
who
> intend to use the CAN-Controller of the LPC2119 or LPC2292 or other
> LPC2XXX derivate.
> 
> If you use 29 Bit identifier, it can happen that the unit will 
change
> content of a received data frame. Identifier and data byte are
> suspected to be corrupted.
> 
> This happens, if the unit looses arbitration to another Can-Node.
> Normally the CAn-Controller will switch over to reception, if he 
had
> lost arbitration and will receive the message of the other node,
> delaying his own message.
> 
> On the actual LPC-CAN-derivates the same happens, but the message,
> which is received in this case, will not contain the data from the
> message, which won the arbitration, but it will contain arbitrary
> Identifier and data bytes.
> 
> This happens using 29 Bit identifiers, and if the identifier of the
> messages in the arbitration battle, have the same leading 12 bits.
>  
> 
> We reported this bug to philips on 25.4.2005 and got a 
confirmation in
> the meantime.
> Finaly we don't understand, why this important information is not 
made

> available in the corresponding errata sheets by philips.
>   
> 
> 
> 
> 
>  
> Yahoo! Groups Links

> > This happens using 29 Bit identifiers, and if the identifier of the
> > messages in the arbitration battle, have the same leading 12 bits.


Two questions:

1) Does "leading 12 bits" mean the first 12 bits transmitted? These are the 
most significant bits in the message Id right?


2) So does this mean that if there is a difference in this area, then the 
arbitration will be OK?


Some form of explantaion of how this might happen:

It is quite easy to see how this bug could happen. For Extended frames (ie. 
29-bit Id) the meddage Id is transmitted as three parts:
1) First (most significant) 11 bits.
2) SRR + IDE bits
3) Remaining 18 bits

The CAN controller likely is matching the first 11 bits and only the first 
bit of the remaining 18 bits.

This will likely break many/most J1939 or SAE11785 systems which will often 
only have differences in the last (lsb) 16 bits.

hi Peter,

The invalid message generated by the can-controller is passed to the
filter stage. So, if the corrupted "new" identifier does not match your
acceptance filter setting, you will receive no message at all.


The german philips fae told us that there is an ongoing redesign
process for all can equipped LPC chips and that new parts may be
available in Q4/2005.


Andreas

That's pretty interesting.  How did anyone ever figure out this 
behavior?  In our case I think we would experience this 1 out of 
about 20,000 arbitrations (randomly generated ID would pass through 
our filter).
James


--- In lpc2000@yahoogroups.com, "alipowsky" <a.lipowsky@g...> wrote:
> hi Peter,
> 
> The invalid message generated by the can-controller is passed to 
the
> filter stage. So, if the corrupted "new" identifier does not match 
your

> acceptance filter setting, you will receive no message at all.
> 
> 
> The german philips fae told us that there is an ongoing redesign
> process for all can equipped LPC chips and that new parts may be
> available in Q4/2005.
> 
> 
> Andreas

> 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.

--- 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.

--- 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%.

Hi All,

I have a project, where my customer demands CAN bus interaction.
Unfortunately I have never worked with CAN only RS485 etc. so it's all new
to me - sorry for the "dumb" questions.

I'm planning to use an LPC device as I need some processing power, but
frankly I'm a bit afraid to use CAN with all the talking about bad CAN
modules. 

1.
Is there a LPC with an "OK" CAN module? 


2.
The project consists of about 700 units communicating with each other.
I'm planning to use twisted pair cable, wiring all the 700 controllers in
series in a large 9 story building so there's a lot of cable! 

3.
Does one need CAN bus "amplifiers" when there are so many controllers and so
many meters of cable? 

4.
I've heard rumors about CAN being fault tolerant, what happens if two
controllers try to "talk" at the same time? - same as RS485 where the
communication is messed up?

5.
On the LPC's there are a CAN "uart" what kind of "transceiver" do I need to
convert the 3.3V signals to what ever it is CAN is using?


Sorry for the newbie questions.

Regards
Lasse

Some answers

--- In lpc2000@yahoogroups.com, "Lasse Madsen" <lasse.madsen@e...
> I have a project, where my customer demands CAN bus interaction.
> Unfortunately I have never worked with CAN only RS485 etc. so it's 
all new
> to me - sorry for the "dumb" questions.
> 
> I'm planning to use an LPC device as I need some processing power, 
but
> frankly I'm a bit afraid to use CAN with all the talking about bad 
CAN
> modules. 
> 
> 1.
> Is there a LPC with an "OK" CAN module? 
They all use the same module as far as I can make out.

It depends what you mean by OK. There are bugs in the CAN module, but 
they can all be worked around one way or another. I have successfully 
used it fine.

> 
> 
> 2.
> The project consists of about 700 units communicating with each 
other.
> I'm planning to use twisted pair cable, wiring all the 700 
controllers in
> series in a large 9 story building so there's a lot of cable! 

CAN will not work like that. You will need to split the system into 
segments with a maximum of perhaps 20-50 nodes or so per section and 
each section with a limited length bus.

> 
> 3.
> Does one need CAN bus "amplifiers" when there are so many 
controllers and so
> many meters of cable? 

Yes, you'd use "bridges" that retransmit packets from one network to 
another.

> 
> 4.
> I've heard rumors about CAN being fault tolerant, what happens if 
two
> controllers try to "talk" at the same time? - same as RS485 where 
the
> communication is messed up?

CAN handles this very well. A 0 is dominant and a 1 is recessive (ie. 
if two nodes drive the bus, one with a 0 and one with 1, then the 0 
will override the 1). As a can node talks it also listens. If it does 
not see what it is sending then it backs off and trries gain in the 
next messaage slot. This means that collisions do not ever destroy 
packets or result in lost bandwidth (as they would on, say, RS485). 
This also means that 100% (or really close) utilisation is possible on 
a CAN network.

The way the dominant/recessive stuff works limits the capacitance and 
bus length. This is the major challenge you face with a 700 node 
system.

> 
> 5.
> On the LPC's there are a CAN "uart" what kind of "transceiver" do I 
need to
> convert the 3.3V signals to what ever it is CAN is using?

Yes Typically the 82C250/251 are used in automotive. You can use 
alternative drivers (basically anything that allows a 0 and 1 to be 
sent in a way that allows the 0 to override the 1 and allows you to 
monitor the bus.

> 
> 
> Sorry for the newbie questions.

We've all been there.

Hi Lasse,

On Thursday 02 June 2005 00:10, Lasse Madsen wrote:
> I'm planning to use an LPC device as I need some processing
> power, but frankly I'm a bit afraid to use CAN with all the
> talking about bad CAN modules.
>
> 1.
> Is there a LPC with an "OK" CAN module?

I don't know problems, if you only use Standard Identifier 
(11-Bit) and BasicCAN.

Do you want receive all Messages from the 700 units?

> 2.
> The project consists of about 700 units communicating with
> each other. I'm planning to use twisted pair cable, wiring all
> the 700 controllers in series in a large 9 story building so
> there's a lot of cable!

Note, that you need a bus structure for CAN.
But I don't know Transceivers, that can drive 700 nodes.
I think you need additional Gateways.

> 3.
> Does one need CAN bus "amplifiers" when there are so many
> controllers and so many meters of cable?

I don't know amplifiers, only gateways.

> 4.
> I've heard rumors about CAN being fault tolerant, what happens
> if two controllers try to "talk" at the same time? - same as
> RS485 where the communication is messed up?

You means the message arbitration, I think. 
Short, this means, that the transmitter with the lowest Message 
Identifier transmit his message at the first.

> 5.
> On the LPC's there are a CAN "uart" what kind of "transceiver"
> do I need to convert the 3.3V signals to what ever it is CAN
> is using?

On my EVA board from Keil is a TJA1040.

> Sorry for the newbie questions.
Some Links:
CAN Wiki: http://www.can-wiki.info/
CiA (CAN in Automation): http://www.can-cia.org/can/
Submit to a CAN Newslist: http://www.canlist.org/

Hope, this help a little bit.

-- 
Steffen Rose
www.port.de