AT90CAN128 CAN bus problem

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

I have a small problem with my CAN bus:
Measured with Salea logic analyzer, it seems, that the CRC field has an additional bit sometimes, which is usually the same, as the last bit of CRC field was. It is not the CRC delimiter bit.
I attach two pictures about my problem. On both of the pictures there is a green marker, showing the CRC field, as it should be. And on both pictures after the second green marker there is an additonal bit before the CRC delimiter bit (the CRC delimiter bit is right before the ACK low bit).

Otherwise my CAN communication seems to work flawlessly. I can send, and receive data without problem.

Can somebody explain, what this strange behaviour is?

Thanks

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bosch CAN specification wrote:
BIT STREAM CODING

The frame segments START OF FRAME, ARBITRATION FIELD, CONTROL FIELD, DATA FIELD and CRC SEQUENCE are coded by the method of bit stuffing. Whenever a transmitter detects five consecutive bits of identical value in the bit stream to be transmitted it automatically inserts a complementary bit in the actual transmitted bit stream.

The remaining bit fields of the DATA FRAME or REMOTE FRAME (CRC DELIMITER, ACK FIELD, and END OF FRAME) are of fixed form and not stuffed. The ERROR FRAME and the OVERLOAD FRAME are of fixed form as well and not coded by the method of bit stuffing.

The bit stream in a message is coded according to the Non-Return-to-Zero (NRZ) method. This means that during the total bit time the generated bit level is either ’dominant’ or ’recessive’.

Since the CAN hardware automatically stuffs and de-stuffs the CAN serial data bit stream as needed, the only interface visibility for bit stuffing in the ATMEL 8 bit CAN chips are the CANGIT.SERG and CANSTMOB.SERR stuff error register bits. Being register error bits the only time you will encounter them is if there is a problem with the CAN serial data stream.
lammelm wrote:
I have a small problem with my CAN bus:
You do not have any problem at all:
lammelm wrote:
Otherwise my CAN communication seems to work flawlessly. I can send, and receive data without problem.
As proven by your own observation :wink:.

Since you are looking directly at the CAN bus serial data stream, you are able to see this automatic CAN controller hardware bit stuffing operation that is normally hidden from the CAN chip software interface (except for the stuff error bits). I expect there are probably other stuffed bits in you CAN bus data stream you may have missed. For example any eleven bit message identifier with more than 5 sequential dominant bits will cause bit stuffing in the Arbitration Field. Be careful, the first 7 bits of the message identifier are not allowed to all be recessive values (as in binary 1111111xxxx). So if you construct message identifier values just for looking at bit stuffing with your logic analyzer, do not go higher than 0x7EF (11 bit CAN part A) or 0x1FBFFFFF (29 bit CAN part B).

Bit stuffing breaks up too many sequential Tx CAN bus serial NRZ data states, where the signal remains dominant or recessive without changing. Forcing the Tx CAN serial data stream to change CAN bus bit states with a stuff bit allows the asynchronous Rx CAN hardware to resynchronize on the stuff bit forced transition change. Any asynchronous timing difference between different CAN nodes will accumulate for all the NRZ bit times where the signal does not change. If ten sequential same value CAN bits were allowed without resynchronization, the single bit asynchronous timing difference would be multiplied by ten. Eventually this accumulated difference could cause Rx CAN nodes to misinterpret the Tx CAN node data bit values. The stuff bit resynchronization corrects this problem and also plays into the CAN clock frequency stability specification limits.

Bit stuffing for NRZ coding is older than CAN is.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Deleting above.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly