CAN Error Handling

Error Handling은 CAN protocol에 정의되어 있으며, CAN 시스템 성능에 매우 중요한 역할을 한다. 

Error Handling은 CAN 버스의 메시지의 오류를 감지하여 일반적으로는 송신기가 오류 메시지를 재전송할 수 있게 하는 것을 목표로 하고 있다. 따라서 버스 내의 모든 CAN controller는 메시지 내에서 오류를 감지하려고 시도한다.

 

일단 오류가 발견되면, 오류를 발견한 노드는 Error Flag를 전송하여 Bus traffic을 파괴한다. 다른 노드는 이 Error flag를 통해서 오류를 감지하고 현재 메시지를 폐기하는 등의 조치를 취한다. 

각 노드는 두 개의 Error Counter, 전송 Error Counter와 수신 Error Counter를 가지고 있다. 이 Counter가 증감하는데는 몇 가지 규칙이 있다. 기본적으로 오류를 감지한 송신기는 수신 노드가 수신 Error Counter를 증가시키는 속도보다 빠르게 송신 Error Counter를 증가시킨다. 이는 일반적으로 송신기에 결함이 있을 확률이 높기 때문이다. Error Counter가 특정 값 이상 올라가면, 노드는 에러를 감지해도 Bus Traffic을 파괴하지 않는 Error Passive 상태가 되고, 그 다음에는 Bus Traffic에 전혀 참여하지 않는 Bus Off 상태가 된다. 

위의 상태도를 살펴보면, 기본적으로 초기에는 전부 Error Active상태이다. 이는 오류를 감지하면 Error Flag를 띄울 수 있는 상태이다. 하지만 Counter가 127보다 크면, Error Passive상태로 간다. 이유는 위에서 이야기한 것과 같이 자꾸 Error Flag를 띄우면 버스 전체를 마비시킬 수 있기 때문이다. 송신 Error Counter가 255보다 커지면 Bus Off 상태가 되어서 아예 버스에서 분리하게 된다.

전송 Error Counter는 8씩, 수신 Error Counter는 1씩 증가한다. 따라서 16번의 전송 오류 발생 시, 127 이상으로 올라가게 된다. 

 

Bus Off에서 벗어나려면, HW reset이나 SW reset 혹은 부가적인 Wait Time 이후에 천이될 수 있다. 

Error Detection Mechanism

CAN protocol에서는 오류를 감지하는 방법을 5 가지 이상 정의한다. 이 중에서 2개는 Bit 수준에서 동작하고, 나머지 3개는 메시지 수준에서 동작한다. 

• Bit Monitoring : CAN bus의 각 Transmitter는 전송한 신호 레벨을 모니터링한다. (다시 읽어들임) 실제로 읽은 Bit 레벨이 전송된 것과 다르다면, Bit Error를 발생시킨다. [Arbitration Process 중에는 Bit Error가 발생하지 않는다. 왜냐면 여러 노드가 동시에 신호를 쏘기 때문에]

 

• Bit Stuffing: 노드에서 동일한 레벨의 Bit를 5개 연속 전송할 경우, 송신자는 반대 레벨의 Bit를 6번째 Bit로 추가해서 보낸다. 만약에 동일한 Bit가 6 bit 이상 발생하면 Bit Stuffing Error를 발생시킨다.

 

• Frame Check : CAN message 일부에는 고정된 형식, 즉 표준에 의해 정확히 어떤 레벨이 언제 발생해야 하는지에 대한 정의가 있다. CAN controller가 이러한 고정 영역 중 하나에서 유효하지 않은 값을 감지하면 에러가 발생한다. 

 

• Acknowledgment Check : 메시지가 올바르게 수신한 버스의 모든 노드는 메시지의 Ack slot에 Dominant level을 전송해야 한다. 만약에 송신기가 이를 감지하지 못하면 에러를 발생한다.

 

• Cyclic Redundancy Check : 각 메시지에는 15bit의 CRC가 있으며, 메시지 자체적으로 계산한 것과 다른 CRC를 감지하면 CRC 에러를 발생한다.