Help Center

Serial Port Utility Help Center

Start with a working connection, then use the focused sections below to diagnose serial, protocol, logging, activation and Cloud Sync questions.

Quick start Troubleshooting

Serial Port Utility Help Center

Quick start

Use this path when you only want to confirm that the software, driver, cable and target device can talk to each other.

  1. Download the latest build from the Downloads page and install it.
  2. Install the USB-to-serial driver required by your adapter or development board.
  3. Plug in the target device and confirm the COM port appears in Device Manager.
  4. Select the port and match the device parameters. A common first try is 115200 / 8 / 1 / None.
  5. Choose Text mode for readable commands or logs. Choose Hex mode for binary frames and byte-level checks.
  6. Send a short known command, then watch the connection state plus Rx and Tx counters.

If the first test fails, do not change many settings at once. Check the port, driver, cable, serial parameters and line ending in that order.

Connection and serial parameters

Serial communication only works when both sides agree on the same link settings.

  • Port: the COM port assigned by the operating system. Re-plugging a device can change it.
  • Baud rate: must match the target device. Common values include 9600, 115200, 460800 and 921600.
  • Data bits: usually 8.
  • Stop bits: usually 1.
  • Parity: usually None, but industrial devices may use Even or Odd.
  • Flow control: keep it disabled unless the device documentation explicitly requires RTS/CTS or XON/XOFF.
  • Line ending: AT-style devices often require CRLF; some older devices require only CR or LF.

Custom baud rates are available, but stable high-speed communication still depends on the serial chip, driver, cable quality and target firmware.

Text and Hex workflows

Use Text mode when the protocol is readable: AT commands, startup logs, console output or line-based messages.

Use Hex mode when the protocol is binary: Modbus RTU, private UART frames, sensor packets, bootloader frames or data that contains non-printable bytes.

Practical checks:

  • If text looks garbled, confirm the baud rate first, then check encoding and display mode.
  • If a binary command does not work, compare the exact bytes in Hex mode.
  • If a command needs a line ending, configure the automatic suffix instead of typing invisible characters manually.
  • Keep sample frames with spaces, for example 01 03 00 00 00 02 C4 0B, so they are easier to review.

Automatic send and command lists

Automatic send is useful for polling, burn-in tests and repeated protocol checks.

  • Loop send: repeatedly sends the current command at a fixed interval.
  • Line-by-line send: sends multiple commands in sequence, one line at a time.
  • Send history: helps reuse common commands during repeated debugging.
  • Pause and Stop: use these states to inspect data or release the port before switching firmware or tools.

For device initialization scripts, put one command per line and test the sequence slowly before lowering the interval.

Logs and long-running capture

Turn on logging when a problem is intermittent or when you need to hand evidence to another engineer.

Recommended logging habits:

  • Enable timestamps for each received and sent line.
  • Use a filename template that includes the port, project or date.
  • Rotate logs by size or time for long tests.
  • Open the current log immediately after the issue appears and keep the original file.
  • Include a small sample frame in support requests so the symptom is reproducible.

For 24-hour tests or production benches, confirm the log location and rotation rule before starting the run.

CRC and Modbus checks

CRC failures are usually caused by one of four things: wrong payload bytes, wrong byte order, wrong CRC algorithm parameters, or missing line/frame boundaries.

Recommended workflow:

  1. Copy the exact Hex payload without the CRC bytes.
  2. Select the expected CRC algorithm, such as CRC-16/MODBUS when the device uses Modbus RTU.
  3. Compare width, polynomial, initial value, xorout and reflection settings if the supplier document lists them.
  4. Append the calculated CRC in the byte order required by the protocol.
  5. Send the frame and compare the raw response bytes.

If a device returns nothing, first confirm the physical link and serial parameters. CRC debugging only helps after the device can actually receive the frame.

TCP and UDP debugging

Serial-to-network modules and gateways often need both sides checked together.

  • TCP Client: connect to a device, gateway or test server.
  • TCP Server: listen locally and observe incoming clients.
  • UDP: test datagram-based protocols, broadcast-like discovery or gateway forwarding.
  • Hex mode: use it for binary payloads over TCP or UDP, not only for serial ports.
  • Logs: save network-side traffic when comparing it with serial-side traffic.

When TCP or UDP fails, check IP address, port, firewall rules, subnet, gateway mode and whether another process already holds the same local port.

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.

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.
  • Check whether the device uses a different text encoding or 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.

Orders, activation and Cloud Sync

The public website separates the desktop debugging workflow from account and service workflows.

  • Downloads: get the current Windows or macOS build and review release notes.
  • Service: purchase, order lookup and offline activation live in the service area.
  • Offline activation: prepare the CID shown by the application and the license information from your order.
  • Cloud Sync: account-based workflows can connect devices, licenses and message records for support or operations.
  • Privacy: review what data is collected before enabling online workflows.

If you only need local serial debugging, start with Downloads and the quick-start steps above.

Before contacting support

Please include as much of this information as possible:

  • Operating system and Serial Port Utility version.
  • Device model, adapter model and driver name.
  • Serial parameters: port, baud rate, data bits, stop bits, parity and flow control.
  • Text or Hex mode, line ending and the exact command you sent.
  • Screenshot of the connection state and Rx/Tx counters.
  • A short log file or sample frames showing both request and response.
  • For orders or activation: order number, checkout email, CID and license type.