--- title: "WIZ750SR-TTL looses connection" url: "https://maker.wiznet.io/forum/16092" markdown_url: "https://maker.wiznet.io/forum/16092/md" type: "Forum topic" category: "Serial-to-Ethernet & ConfigTool" author: "gsmiderle" created: "2026-06-11T00:28:34+09:00" last_activity: "2026-06-23T11:08:01+09:00" language: "en" views: 5 replies: 5 source: "WIZnet Makers forum (https://maker.wiznet.io/forum/)" --- # WIZ750SR-TTL looses connection ## Question Asked by gsmiderle on 2026-06-11 in Serial-to-Ethernet & ConfigTool. Hi, I have a **WIZ750SR-TTL used to convert a UART Modbus signal to an Ethernet one, so I can communicate with a Safety PLC that has only Ethernet.The thing is that I lose the communication around once a day, I've tried to remove the gateway and DNS (since I do not need to connect to the internet), I've tried to lower the retransmission test, I've tried to enable keepalive. I've managed to increase the reliability with the fw of the STM32 on the UART, but now I'm stuck.When I connect a pc with Wireshark to identify the problem, the problem never appears.By searching online, it could be a problem with the auto-negotiation of the speed. Is there a way to fix it?Do you have any other tips to check? ** ## Replies ### Reply 1 by Grace_Koo, 2026-06-11 Hi, The fact that the problem disappears when you connect a PC with Wireshark is actually a very strong clue — it points to an ARP cache expiration issue rather than a physical layer (auto-negotiation) problem. Here's what's likely happening: When only the WIZ750SR and the Safety PLC are connected (with very little traffic between Modbus polls), the ARP entry on the PLC side expires after a certain period. When the next TCP packet needs to be sent, the PLC has to re-resolve the MAC address via ARP. During this re-resolution window, the TCP connection can time out and drop. When you connect your PC running Wireshark, it generates broadcast traffic (ARP requests, etc.) that keeps the ARP tables on both devices refreshed — so the problem never appears. To verify and fix this: 1. Check if your Safety PLC supports static ARP entries. If so, manually add the WIZ750SR's IP and MAC address as a static entry. This prevents the ARP cache from expiring. 2. Reduce the keepalive interval on the WIZ750SR to a value shorter than the PLC's ARP timeout (typically 30-60 seconds should work). The keepalive packets will also serve to refresh the ARP cache on both sides. 3. If you're using a managed switch between the two devices, you can also check the switch's ARP/MAC address table aging time and increase it. I would start with the static ARP entry on the PLC — it's the most reliable fix for this type of issue. Let us know if this resolves your daily disconnects. ### Reply 2 by gsmiderle, 2026-06-11 (in reply to reply 1) Thanks for the tips! The PLC does not have something like that. I'm waiting for their response to see if there is something they can do. The strange thing is that the communication is really fast, I have requests from the Wiznet (it's the master) every 20ms, so the keepalive never starts (right now it is at 20s for the first and then 5 sec). Does the same thing apply even for the ARP timeout? Aren't all these requests to the PLC enough to sustain the ARP tables? . *UPDATE* I can confirm that with a managed switch, the connection does not drop. The strange thing is that the 2 devices are on a single VLAN, the pc in in a port with port monitoring, so there should be 0 communication between the devices and the pc, yet the connection does not drop. Unfortunately, the connection needs to stay up even with other switches or with none. Any ideas? ### Reply 3 by gsmiderle, 2026-06-22 UPDATE! It seems like the problem is the 750 itself, I tested the communication with an old 7100,A and it works just fine. Do you know if there is any fix for this without changing the cip? ### Reply 4 by Grace_Koo, 2026-06-23 (in reply to reply 3) **(Revised)** Your testing points to a link-layer (Ethernet PHY) interoperability behavior in this specific point-to-point setup — the WIZ750SR and the PLC don't always settle into a stable auto-negotiation when connected directly, whereas a managed switch (which terminates each link independently) resolves it cleanly. The fact that the older 7100 behaves differently here is consistent with a difference in PHY negotiation between the two setups rather than a Modbus or PLC issue. (This also rules out ARP — with 20 ms polling, ARP stays refreshed and keepalive never starts.) Options without replacing the module: 1. When it fails, check link LED, ping, and TCP socket state — this separates a PHY/link problem from a TCP/socket firmware problem. 2. Force both ends to the same fixed speed/duplex, ideally 10 Mbps first, then 100 Mbps full — Modbus traffic is tiny and 10BASE-T is far more tolerant. Never force only one side (duplex mismatch). 3. Add connection-level auto-recovery: if no Modbus response within a timeout, reopen the socket and re-init the PHY/stack so a dropped link recovers in under a second instead of staying down. (Hang-level recovery is handled separately by the built-in watchdog — see below.) 4. Use the built-in watchdog: firmware v1.4.0 added a watchdog function (bug fixed in v1.4.1), so on v1.4.1+ the module can recover from a hang on its own — just make sure you're on a recent build and the watchdog is enabled. 5. Update firmware: beyond the watchdog, the changelog includes W7500P PHY-stability fixes and Modbus improvements — Modbus RTU/ASCII was added in v1.4.4 and refined in v1.4.5 (current latest). Since you're running Modbus, moving to v1.4.5 is recommended. Recommended order: check firmware version (update to v1.4.5 if behind) → if point-to-point is required, force 10 Mbps fixed and add connection-level auto-recovery in custom firmware → otherwise standardize on a switch with the WIZ port forced. ### Reply 5 by Grace_Koo, 2026-06-23 (in reply to reply 3) One more note: keeping a small managed switch inline isn't just a workaround — since the root cause is at the link/PHY-negotiation layer, the switch genuinely stabilizes it, so it's a valid permanent fix if point-to-point isn't a hard requirement. And if a firmware update to the latest version doesn't fully resolve the daily drops, please email Grace@wiznet.io with your current firmware version and setup details. --- Source: https://maker.wiznet.io/forum/16092