Update device firmware over serial

Scenario 8: update a device's firmware over the serial link

Use this when a microcontroller, gateway or instrument takes its firmware through a bootloader that speaks YMODEM, and the update is currently done from a second terminal program.

1. Connect to the device's serial port and set the bootloader's baud rate. It is often not the one the application runs at, and this is the single most common reason an update never starts.
2. Put the device into its bootloader — a reset with a button held, a command, or whatever the manual specifies. The receive view should start showing C characters about once a second: that is the bootloader asking for a file.
3. Choose Connection → Send File…, pick YMODEM, and select the image. Check the grey summary line at the top of the dialog before confirming; it reads the port, baud rate, framing and flow control back to you.
4. Watch the strip above the receive view: file name, bytes transferred, rate, time remaining and retry count. A retry count climbing above zero points at the baud rate or the cable, and it is worth stopping early rather than waiting for the tenth failure.
5. When the transfer completes, the receive view returns to showing the device. Confirm the device restarts into the new firmware before disconnecting.

The transfer takes the port over for its duration: the Send button, automatic send, terminal keystrokes, Break, DTR/RTS and serial parameter changes are all refused with a reason while it runs, because any of them would end the update.

If the device's manual asks for XMODEM instead, choose XMODEM-CRC or XMODEM-1K. Note that XMODEM carries no length field, so what the device receives is padded up to a whole number of blocks — use YMODEM whenever the image is checksummed.

If the update is interrupted, run the whole update again. A cancelled send still delivers up to one more block, and a dropped connection is never resumed automatically: nothing on this side can know what state the device's flash is in, and something that looks like it worked is the worst outcome.

Update a device on the other side of a device server

Anything that speaks RFC 2217 as a server works: a Moxa NPort, ser2net, or another machine running this application in server mode. The steps are the same: pick Remote Serial (RFC 2217) in the Port list, set the bootloader's baud rate on the remote port, then send the file over the same connection.

Plain TCP forwarding can carry the file too, but it cannot change the remote port's baud rate — and a bootloader usually runs at a different rate from the application. Doing both over one connection is what makes an update from the office to a device in the field work end to end.

Update a device that dialled in to you

For a 4G DTU or edge gateway that opens the connection itself, run a TCP Server and send to it. A transfer pins one client when it starts: with several connected, select the one you mean in the client list first — there is deliberately no "first client" fallback, because flashing firmware into the wrong device is not something you notice immediately. Every other client keeps working normally throughout.