CAN Bus Communications Decoded: CAN Errors
Watch This Course
$199 USD $99.50 USD
-OR-
Or
8 easy payments of only $12.44
Instant access. Easy checkout. No fees.
CAN Errors
02.37
| 00:00 | - Because CAN is used in safety critical devices, a lot of thought has gone into designing the protocol to be fault tolerant and have it report errors as they occur. |
| 00:09 | To facilitate this, as each device is reading the data on the bus, it will be continuously making sure that the data obeying the rules of the CAN protocol. |
| 00:18 | If a transmitting or receiving device detects any frame traffic on the bus that breaks the protocol rules, it will immediately transmit an error frame which destroys the traffic on the bus. |
| 00:29 | Every other device then knows that the frame which was being transmitted is corrupt somehow and should be ignored. |
| 00:36 | There's a complicated scheme of tracking these errors with counters that get incremented and decremented in response to detected errors and correctly received messages. |
| 00:44 | We won't go into the mechanics of the system in detail because it's outside the scope of the course but we will talk about how we can affect our performance or reverse engineering applications. |
| 00:53 | A device on the bus has 3 error states it can be in, error active, error passive and bus off. |
| 01:00 | Error active is where all devices start. |
| 01:03 | In this mode, devices try to receive and transmit data as usual but when they detect an error, they transmit a dominant error frame which destroys the traffic on the bus, letting every other device know that something is wrong. |
| 01:17 | If a device encounters enough errors it will escalate its error mode to error passive. |
| 01:22 | In this mode, the device will still try and communicate as normal, but instead of transmitting a dominant error frame when it detects an error, it will transmit a passive error frame. |
| 01:31 | This doesn't destroy the traffic on the bus but will still log an error within that device. |
| 01:36 | The next level of escalation is bus off. |
| 01:40 | When a device enters this state, it removes itself from the bus all together and will no longer receive or transmit any messages until it is reset. |
| 01:48 | This escalation scheme might seem a little bit odd but it's based on the fact that devices on the bus are more likely to detect errors within their own transmission than other devices are. |
| 01:58 | So as they detect errors, they move further and further towards removing themselves from the bus as they are the likely source of the error in the first place. |
| 02:06 | Once again, it's not crucial to understand the complete mechanics of error detection and error frames, just to know that they exist. |
| 02:13 | Most devices will have a status flag somewhere, showing the device error state. |
| 02:17 | Which can help with tracking down problems. |
| 02:19 | 99% of the errors I encounter are because of simple things though. |
| 02:24 | The bus speed being set incorrectly, CAN high and CAN low being mistakenly swapped around or termination resistors either not being installed or installed in the wrong place. |
