0
\$\begingroup\$

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: enter image description here

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.

\$\endgroup\$
7
  • 1
    \$\begingroup\$ For starters, that's more like a block diagram, not a schematic. The component types and values are nowhere to be found. Please add them. For example the diagram looks like the master, not the slave. Does your slave really have the bias and termination resistors present? And do you only have two wires on the bus? Do you have oscilloscope to debug the issue? You don't get very far by just sending and receiving data and PC saying it received incorrect data. \$\endgroup\$
    – Justme
    Dec 28, 2023 at 9:49
  • \$\begingroup\$ Well, shorting the output with diodes would be a problem. Or, if they aren't PN diodes but TVS or something -- well, that's why we need to know. \$\endgroup\$ Dec 28, 2023 at 9:54
  • \$\begingroup\$ OK, I think I know the largest issue, but that depends what components are present, what are their values, and if there are any other major mistakes. Like is there a common ground reference between RS-485 devices or not, and if there is even a single bypass cap in the design. I will post an answer after OP provides the requested necessary info. \$\endgroup\$
    – Justme
    Dec 28, 2023 at 9:59
  • \$\begingroup\$ @Justme The IC is MAX485. The resistors are 120 ohms (for termination) and 4.7K (for failsafe biasing. The diodes are TVS diodes (SMBJ6.5CA) \$\endgroup\$ Dec 28, 2023 at 10:34
  • 1
    \$\begingroup\$ @nottherealfaraday Please add all the new information to the question. And what do you mean by bypass capacitors on the RS485 side, do you mean on the supplies or on the data wires? \$\endgroup\$
    – Justme
    Dec 28, 2023 at 10:41

1 Answer 1

5
\$\begingroup\$

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.

\$\endgroup\$
4
  • \$\begingroup\$ Thanks for the valid points. Apparently none of this was causing the issue. The RS485 to serial converters which we were using were both problematic and this was the reason for the failures. Changed the converters and it started working like a charm. No failures. \$\endgroup\$ Jan 1 at 9:40
  • \$\begingroup\$ @nottherealfaraday Changing the PC RS485 adapters to ones than can cope with the design issues I mentioned does not fix the design issues and the design issues are the reason why it does not work with all RS485 adapters to begin with. I still think your design causes issues. The bus is biased incorrectly, there are no ground reference between devices, there are no bypass caps on MAX485, and there is a termination resistor, and a ModBus slave should not terminate or bias the bus. Who knows what other problems the AVR design has which you are not showing. \$\endgroup\$
    – Justme
    Jan 1 at 9:45
  • \$\begingroup\$ Yes, thanks a lot. Apparently, these design issues were present in our other devices too and I'll be fixing them. We do have bypass capacitors and a ground reference through common power supply. The last slave is supposed to terminate the bus, no? What do you mean by the problems in AVR design? What information do you need to talk about it? I've also been wondering how the delay I added before and after changing the DE pin status in the code might be affecting the communication. Currently it's 100ms. Is there a recommended value for this? \$\endgroup\$ Jan 3 at 2:56
  • \$\begingroup\$ Last slave is supposed to terminate. So you can't put no more than 1 of your slaves on the bus and it must be last if all your devices have termination. And only one device that implements biasing is allowed, so if the msster already implements biasing, you can't put any of your devices on the bus. 100ms DE delays before and after data transmission limits the bus throughput as the bus master must wait more than 100ms for the response and can't communicate a new command until 100ms after receiving a response from your slave. I don't know ModBus enough if this is within limits. \$\endgroup\$
    – Justme
    Jan 3 at 6:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.