Response partly lost in Modbus RTU over RS485 communication

Question

I have developed a Modbus slave which uses ATMega8A and MAX485. In a new lot of the devices, while testing them on my PC using QModMaster, the response that I get has one byte in front of it, and cuts-off at 8 bytes. The rest of it doesn't come, and therefore I get a CRC error.

Sample request and response:

[RTU]>Tx > 12:52:13:603 - 04  03  00  03  00  1B  F5  94  
[RTU]>Rx > 12:52:13:603 - 00  04  03  36  00  00  00  00  
Sys > 12:52:13:603 - Error : Invalid CRC
[RTU]>Tx > 12:52:14:596 - 04  03  00  03  00  1B  F5  94  
[RTU]>Rx > 12:52:14:597 - 00  04  03  36  00  00  00  00  
Sys > 12:52:14:597 - Error : Invalid CRC

Correct response looks like this:

[RTU]>Tx > 14:12:02:251 - 04  03  00  03  00  1B  F5  94  
[RTU]>Rx > 14:12:02:466 - 04  03  36  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  00  7F  8D  

The funny thing is.. this happens only sometimes. At other times, the device sends data continously without error. I've also never observed the issue in a session when it sends the data. That is, if it sends the data correctly it sends it forever. If it doesn't, it doesn't. I've tried left and right to find out what might be causing the issue by checking the hardware. I can't even reliably recreate the issue.

The circuit, for reference:

J3 is shorted on the board.

I've done obvious things like:

• Changing the RS485 to serial converter
• Changing the laptop and master software used for testing I've also:
• Run the ATMega8a from a different 5V power supply (the device is given 24V, and uses LM2576 to generate 5V)

The issue occurs by chance under all these conditions.

Some points:

• There are no pull-ups or pull-downs on the controller side of MAX485
• I've given a 100ms delay after toggling the DE pin before and after transmitting data.

Could this be a problem with one batch of ICs? If it's an IC problem does it present itself intermittently? I was under the impression that if it's an IC problem, it should just not work, or send garbled data atleast.

I've put the same pair of MAX485 and ATMega on a different device, and it has been working fine. Although I wouldn't say that I have extensively tested it to the generate the issue.

Need to find the issue, and I don't have much time. I'm left with trying things trial and error, but I would like some good suggestions.

Answer 1

OK, the design has many errors that might be responsible of the problem. I recently answered a similar issue but this needs more explaining so I will not mark this as duplicate.

First issue is that for some reason you think RS-485 is a two-wire bus. It isn't. Sure, there are two data wires, and there should be around +/- 5V difference between two data wires. But devices on RS-485 bus cannot just be connected together with two wires, they need to share the same ground via some route. You can only have about +/- 7V difference between the devices or the chips can't operate properly and may damage if there is more difference between grounds. So basically, even if transmitter puts 5V between wires A and B, the receiver cannot sense what is transmitted if it sees 25 and 20V even if 25-20 is 5V. That is why there needs to be a third wire, a wire between the ground pins of the RS-485 transceiver ICs, to keep the grounds of the transceiver ICs at the same potential.

But the above issue might not apply to your problem if you accidentally have the devices sharing a ground reference through power supplies or other cabling.

What is likely the issue is the fail-safe biasing pulling the lines opposite to what they should be.

Your design pulls up B and pulls down A. So every time any of the transmitters are disabled and the bus is left floating with the bias resistors, and because they pull to wrong polarity, that is the same as pulling UART data wire to low level, and effectively sending a break condition with UART. That is received by UART as 0x00 byte with framing error because stop bit is low instead of high.

The correct idle state would be same as sending high level, which means pulling A wire high and B wire low.

But if you are making a ModBus slave, it's not the job of the slave to either terminate the bus or bias it. At least not on the PCB, or without selection of if you want it to terminate or not, if it is not the last device in the chain. Only first and last devices terminate, or leave the termination external to the devices. If all devices have internal unswitchable termination, you can onlu have two devices on the bus, and they must be at the ends of the cable.

Not to mention, your design shows no bypass capacitors on the power supplies. As there is no schematics of the design it is hard to know if this is yet another source of weird glitches, but there really should be a bypass capacitor on each and every power supply pin pair of an IC.