This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 1001897] lpc2xxx CAN driver improvements / enhancements

Please do not reply to this email, use the link below.

--- Comment #8 from Bernard Fouchà <> ---
(In reply to comment #3)
> manual snippet ------------------->
> If the Transmit Error counter contains 255 and another error occurs, the CAN
> Controller is forced into a state called Bus-Off. In this state, the
> following register bits are set: BS in CANSR, BEI and EI in CANIR if these
> are enabled, and RM in CANMOD. RM resets and disables much of the CAN
> Controller. Also at this time the Transmit Error Counter is set to 127 and
> the Receive Error Counter is cleared.
> <----------------------

The manual is unclear: in some places it states that bus off is reached when
the tx counter error is 255, and in what you show (in what is also in LPC17xx
manual section 16.8.1), that bus off is reached only when the counter reaches

For instance the definition of BS is:

"7 BS[6] Bus Status. 0 0
0 (Bus-On) The CAN Controller is involved in bus activities
1 (Bus-Off) The CAN controller is currently not involved/prohibited from bus
because the Transmit Error Counter reached its limiting value of 255."

By readins this one could understand that BS is set when TEC reaches 255, but
the complete bus off state is reached only when the counter is incremented
another time.

> That means: 
> 1. Bus error interrupt
> 2. RM in CANMOD set (RM - Reset Mode resets and disables much of the CAN
> Controller)
> 3. TX counter is set to 127 and RX counter is cleared.
> That means according to the manual the hardware should do exactly what my
> patch does in case of a Bus-off confition. The problem is, although it is
> written in the manual, it does not happen for my LPC2xxx. Via debug output I
> can see the following:
> 1. Bus error interrupt occures (BS in CANSR and GSR is set)
> 2. RM in CANMOD is NOT set (controller remains active)
> 3. TX counter is NOT set to 127 and RX counter is NOT cleared.
> So the hardware acts differently than the manual states. I could not find
> anything in the errata sheets and I don't know if this also happens for
> newer (i.e. LPC3xxx) devices - but for the LPC2294 controller on the olimex
> board, this is reality. Because the controller does not enter RM (Reset
> Mode) and because the counters are not cleared by hardware, the Bus error
> interrupt will happen immediatelly again as soon as the ISR / DSR processing
> has finished. This will block application from running because the ISR /DSR
> code will fire again and again. So my patch simply does, what it is written
> in the manual:

Still about BS, there is a note [6] that states:

"[6] Mode bit '1' (present) and an Error Warning Interrupt is generated, if
enabled. Afterwards the Transmit Error Counter is set to '127', and
the Receive Error Counter is cleared. It will stay in this mode until the CPU
clears the Reset Mode bit. Once this is completed the CAN
Controller will wait the minimum protocol-defined time (128 occurrences of the
Bus-Free signal) counting down the Transmit Error
Counter. After that, the Bus Status bit is cleared (Bus-On), the Error Status
bit is set '0' (ok), the Error Counters are reset, and an Error
Warning Interrupt is generated, if enabled. Reading the TX Error Counter during
this time gives information about the status of the
Bus-Off recovery."

Why did they wrote "afterwards" ? Does it mean that parts of the processing
(TEC set to 127 and REC to zero) only occurs *after* the interrupt?

If so a possibility of what you observe is that TEC reaches 255, BS is set to
one, ISR is triggered, but TEC/REC aren't modified yet. RM is still zero since
TEC just got 255, and didn't crossed yet 255+1 so full bus off isn't reached.

In the meaning time the bus is idle (AFAIK when you debug the CAN cell is still
running), the controller sees 128 'bus free' bits, TEC goes down until the
controller restart trying to send a frame that nobody acknowledge. Or the bus
can't handle recessive bits, etc. From that moment TEC goes up, until the ISR
is fired again.

What is the frequency of the ISR being triggered? Did you test how this
frequency is related to the bus bit rate ? Just to know if when the ISR fires
"again and again" it fires immediately one ISR after the other, or if there is
time for 128 bus free bits on the bus...

You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]