This is the mail archive of the ecos-bugs@sourceware.org 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.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001897

--- Comment #9 from Uwe Kindler <uwe_kindler@web.de> ---
> 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 255+1.
> 
> 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
> activity
> 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.

The CAN standard from Bosch and also the manual of the LPC2xxx is clear in this
point:

Manual:
If the Transmit Error counter contains 255 and another error occurs, the CAN
Controller is forced into a state called Bus-Off.

This is also the same that is written here
http://www.kvaser.com/zh/about-can/the-can-protocol/23.html:
When any one of the two Error Counters raises above 127, the node will enter a
state known as Error Passive and when the Transmit Error Counter raises above
255, the node will enter the Bus Off state.

And that is how it is implemented in LPC2xxx CAN controller.



> "[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?

The LPC2xxx manual is more precise here:


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

So they write: "Also at this time the..." and not "afterwards"

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

No. BS is set if TX counter raises above 255. 

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

As soon as DSR processing has finished and interrupt is unmasked at the end of
DSR via cyg_drv_interrupt_unmask, the ISR fires again. And that is normal
because Bus-Off condition still exists and RM (Reset Mode) is not activated and
BS in CANSR is still set.

-- 
You are receiving this mail because:
You are the assignee for the bug.

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