Troubleshooting checklist

Troubleshooting checklist

Port does not appear:

• Re-plug the USB device and try another cable or USB port.
• Check Device Manager and install the correct CH340, CP210x, FTDI or vendor driver.
• Confirm the device is powered and not in firmware-update-only mode.

Port cannot open:

• Close other serial tools, IDE monitors and firmware flashing tools.
• Re-check the COM number after device reboot.
• Try unplugging and plugging the adapter again.

Device resets or enters the bootloader when the port opens:

• Clear DTR and, if the board uses it, RTS before opening the port.
• Confirm the board's boot strap sequence and remember that USB adapters may invert the logical signal.
• If RTS/CTS flow control is enabled, RTS is driver-managed; disable hardware flow control before attempting a manual sequence.

No data received:

• Confirm baud rate, parity, data bits and stop bits.
• Confirm the target device actually sends data or replies to the command.
• Check TX/RX wiring and RS485 A/B wiring.
• Try a known-good command and a slower send interval.

Garbled data:

• Start with baud rate and parity.
• Switch between Text and Hex to decide whether the raw bytes are correct.
• If ASCII is fine and only Chinese, Japanese or Korean characters are wrong, it is a character encoding problem: set the encoding in Receive Setting to the one the device actually uses (GB18030, GBK and Big5 are common on Chinese devices). Receive and send are configured separately.
• If even ASCII is wrong, the cause is usually baud rate or parity rather than encoding — or the device speaks a binary protocol.

RS485 device does not respond:

• Confirm A/B wiring, termination and common ground.
• Make sure only one master is sending.
• Verify device address, function code and CRC.

High baud rate is unstable:

• Shorten the cable and use a better adapter.
• Reduce the display load and enable logging.
• Validate the exact rate before relying on it in long tests.

Direct RFC 2217 remote serial will not connect or parameters never change:

• Confirm the client can reach the server's IP address and port directly, normally on the same LAN or an already connected VPN.
• Confirm the peer is an RFC 2217 device server rather than a plain TCP-to-serial converter; only the former answers parameter negotiation.
• Check whether "Keep the remote port's own configuration" is still ticked in the connection panel: while it is, nothing is pushed, and the baud rate shown on screen is only a local default, not the remote's actual setting.
• When this machine is the RFC 2217 server, confirm the bridge protocol is set to RFC 2217, not Transparent; Transparent only carries bytes and never answers parameter commands.

A bridge's TCP server cannot be reached from another machine:

• Confirm the listen address is not 127.0.0.1; binding only to loopback makes the port physically unreachable from elsewhere.
• Check that Allowed clients includes the connecting IP or its CIDR subnet; an empty list means no source restriction.
• Confirm the host firewall allows the listening port, including any firewall or security group between the source and destination networks.

Cloud Console shows no live events:

• Confirm the desktop app is signed in with the same account the remote engineer is using — different accounts cannot see each other's online computers.
• Allow up to about 30 seconds on first connect; if nothing appears after that, check whether Cloud Console is actually enabled on the desktop.
• To send commands or change port settings remotely, confirm the site has separately turned on Allow Remote Send / Allow Remote Port Control — both default off and do not turn on just because a session connected.