Thursday, December 17, 2015

Gotchas with updating firmware over RS232

I've recently been upgrading Boland BVB25 OLED monitors over their RS232 serial ports; aside from needing a USB/serial adaptor (I use the Keyspan which mimics an old PC serial UART) you also need a null-modem cable (i.e. where Tx and Rx are swapped over). You can tell if a null-modem cable is required by the sex of the connector on the back of the equipment. A 25-way or 9-way D(male) indicates a DTE ("Data Terminal Equipment" - a PC or terminal) and a female connector a DCE ("Data Communication Equipment") - a modem in RS232 speak. So, if the gear is a DTE then you need a F-F cable and by definition is has to be a cross-over (AKA "null modem" cable. I've banged on about this in the past, and there is also the consideration of handshaking; does you gear/app need the hardware pins (DSR, DTR, DCD etc) or does it use software flow-control (XModem etc). Hugh and I did a podcast on the subject if you need to brush up on your serial comms.
Anyway, because RS232 is such a low level way of doing things it's often the case that the receiving UART in the equipment can get direct memory access before the OS has loaded and you may need to jump through some hoops to get the thing into "serial update mode". In the case of the Boland monitors we sell it's necessary to have the updater software running and looking for comms before you do a power-down reset of the monitor; and not just power-down - tug the power cord, and then within a second or so of re-applying the power the monitor will start talking and appear dead from it's front panel but stuff is going on.

This kind of three-finger tomfoolery really reaches a zenith when you're upgrading the Linux SOC kernal on Amulet DXiP cards!

No comments: