Forum Menu




 


Log in Problems?
New User? Sign Up!
AVR Freaks Forum Index

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
gwentech
PostPosted: Feb 11, 2012 - 02:04 PM
Newbie


Joined: Jan 26, 2011
Posts: 6


In trying to use the UC3C CAN bus interface, I am getting a CAN_STATUS_BUSOFF status. There isn't much documentation on this that I can find. Anyone know what I'm doing wrong?
 
 View user's profile Send private message  
Reply with quote Back to top
Mike B
PostPosted: Feb 11, 2012 - 03:51 PM
Raving lunatic


Joined: Jun 22, 2004
Posts: 3849
Location: South West Utah, USA

UC3C data sheet wrote:
29.6.2.4 Errors and fault confinement
This section refers to chapter 6 (Error handling) and chapter 7 (Fault confinement) of the CAN Specification.
The Bosch CAN Specification Version 2:
http://www.semiconductors.bosch.de/medi ... n2spec.pdf

This ATMEL application note has just a little more information (not much really) - AVR32129: Using the 32-bit AVR UC3 CANIF:
http://www.atmel.com/dyn/resources/prod ... c32152.pdf

Bus off is a CAN node Tx error confinement state that is triggered by repeated Tx errors in a sending CAN node. Bus off is the final state in response to the repeated Tx errors, so there should be information on at least the last Tx type of error. The AERR: Acknowledge Error Status, all by itself (with no other errors) is the only repeated Tx error that will not eventually cause a bus off.

Usually bus off is caused by bad baud rate programming, using the wrong oscillator that is not stable/accurate enough for the Bosch specification, incorrectly configured CAN transceiver chip hardware, no termination on each CAN bus end, badly out of specification CAN bus wiring characteristic impedance, too long of a CAN bus for the CAN baud being used, marginal/unstable CAN bus voltage levels (too much ground offset between nodes, etc.). Finding out what the actual Tx errors are will at least give you a clue about what is happening.

Crystal oscillator stability/accuracy is required from above 125 kbps to 1 mbps CAN baud. Ceramic oscillator stability/accuracy may be used from 125 kbps on down, if a special modified baud rate protocol is used. Any oscillator type that is less stable/accurate is not reliable enough for CAN use. You should have an external crystal or external ceramic resonator clock source.

Sometimes CAN transceiver chips with EMI control input pins get wired incorrectly for the CAN baud being used (EMI control has CAN baud speed limits when it is used).

If possible (meaning you have complete control over all CAN nodes on your network) just for testing/development simplify and reduce your CAN baud rate (like 100 kbps or lower) and CAN bus wiring length (no more than 2 meters). See if there are any application notes for whatever CAN bus transceiver chip you are using. Get the transceiver chip data sheet and check its setup.
 
 View user's profile Send private message  
Reply with quote Back to top
gwentech
PostPosted: Feb 12, 2012 - 02:12 AM
Newbie


Joined: Jan 26, 2011
Posts: 6


Thanks for taking the time; That's a very thorough explanation. I'm using the UC3C_EK eval board, just connecting the 2 can ports together (CAN_H to CAN_H and CAN_L to CAN_L - grounds are already common). I figured the modified example of sending out port 1, receiving on port 0 would work easily, but receiving seems to be a problem. I'll keep plugging away at it.
 
 View user's profile Send private message  
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits