What causes a Modbus CRC error, and how do I fix it?
Updated 18 September 2026
A CRC error means a Modbus RTU message arrived but its checksum did not match, so the receiver knows the bytes were corrupted in transit and throws them away. It is almost always a physical or serial-settings problem, not a software one: electrical noise on the RS-485 line, missing or wrong termination, a baud-rate or parity mismatch, or two devices talking over each other. One software cause exists and is worth ruling out first — feeding RTU frames to a tool expecting Modbus TCP, or the reverse, which makes every message look corrupt.
What the CRC actually is
Every Modbus RTU message ends with a two-byte CRC — a number calculated from all the preceding bytes. The receiver recalculates it and compares. If a single bit changed on the wire, the two will not match, and the receiver discards the frame rather than acting on corrupted data. So a CRC error is not the protocol failing; it is the protocol doing its job and catching damage. Modbus TCP has no CRC — the TCP layer handles integrity — so CRC errors belong to RTU and RTU-over-TCP.
The causes, most common first
1. Wrong framing (the software one, rule it out first)
If a tool set to Modbus TCP is pointed at an RTU-over-TCP gateway, or a tool expecting RTU receives clean TCP frames, every message looks malformed and can be reported as a CRC or framing error. Before chasing cables, confirm you are speaking the right dialect. See TCP, RTU or RS-485 — which do I have?
2. Baud rate, parity or stop bits mismatched
Every device on an RS-485 chain must use identical serial settings. If one is at 9600 8N1 and the master is at 19200 8E1, the bytes are misread and the CRC never matches. This produces consistent, every-message CRC errors — which is actually a helpful signature, because intermittent errors point elsewhere.
3. Missing or wrong termination
A long RS-485 run needs a termination resistor (typically 120 ohm) at each end, and only at the ends. Missing termination causes reflections that corrupt bytes, and the symptom is classic: it works on the bench with a short cable and fails once it is installed on a long one. Too much termination — a resistor at every device — loads the line down and does the same.
4. Electrical noise
RS-485 near variable-speed drives, contactors or motor cabling picks up interference. Intermittent CRC errors that get worse when a big load switches on are the tell. Fixes are shielded twisted-pair cable, a proper ground on the shield at one end only, and routing the data cable away from power.
5. Two devices on the same unit ID
Duplicated unit IDs make two devices answer at once; their replies overlap on the wire and arrive as garbage that fails the CRC. If a chain worked until equipment was added, suspect this first. See what is a Modbus unit ID?
6. A and B swapped, or a marginal connection
Reversed data lines, a loose terminal, or a nicked conductor all corrupt bytes intermittently. Vendors disagree on which wire is A and which is B, so swapping them is a normal diagnostic step, not a mistake.
How to narrow it down
| Pattern | Points at |
|---|---|
| Every single message fails | Baud/parity mismatch, or wrong framing |
| Intermittent, worse on long cable | Termination or noise |
| Intermittent, worse when a load switches | Electrical noise |
| Started when a device was added | Duplicate unit ID, or termination now in the wrong place |
| Only over the network, never local | Framing — you are on RTU-over-TCP |
Because Modbus TCP carries no CRC, moving a stubborn serial device onto a proper translating gateway can make the problem disappear entirely — the integrity check becomes TCP's job over clean Ethernet. It treats the symptom rather than the cause, but on a noisy site it is often the pragmatic fix.