Serial Port Probing

With C62 replaced and the amp powering up, I connected the mini USB cable and opened /dev/ttyUSB4 at 115200 8N1 to see what the LPC2103F had to say for itself.

Silence. Complete silence. No boot banner, no command prompt, no error messages, nothing. The modem control lines confirmed the MCU was alive and well — CTS, DSR, and CD all asserted — but the UART was transmitting exactly zero bytes. I tried every obvious approach: sending ? for the ISP auto-baud sync, AT commands, STX/ETX framing, binary sync patterns (0x55, 0xAA 0x55), plain ASCII commands (version, help, CONNECT), and ENQ (0x05). I swept baud rates: 115200, 9600, 38400, 19200. I ran detect_baud_rate across 16 standard rates to see if the MCU was whispering at a frequency I was not tuned to.

Nothing came back. The application firmware is deliberately mute on the UART in OPERATE mode.

The UPDATE switch discovery

I flipped the rear panel switch to UPDATE, power-cycled the amp, and expected to land in the LPC2103F’s ISP bootloader. The ISP bootloader in NXP’s LPC2100 series activates when pin P0.14 is held low during reset. If the UPDATE switch connected to P0.14, the MCU would skip the application firmware entirely and enter its ROM-based bootloader, which responds to a ? character with Synchronized\r\n.

The amp came up normally. The VFD lit up, the menu system was fully functional, the rotary encoder worked. The application firmware was running.

What we concluded — and why it was wrong

At this point I concluded that the UPDATE switch must be a GPIO input that the application firmware reads after normal boot, entering a software-level “update ready” mode with its own UART protocol. This was a reasonable inference from the evidence available, but the firmware analysis proved it completely wrong on every count.

The UPDATE switch does not connect to the LPC2103F at all. It controls the D2-81431’s BMS[3:0] boot mode pins — choosing between self-boot from EEPROM (OPERATE, Mode 7) and slave boot from the host MCU (UPDATE, Mode C). The LPC2103F’s ISP bootloader entry is controlled by a separate mechanism: jumper JP24, which pulls P0.14 LOW during reset. These are two independent switches on two independent chips.

More fundamentally, UART0 is TX-only. The firmware sends one boot string at 9600 baud — "SNAPAV EPISODE\nEA500 AMPLIFIER" — and never reads or writes the serial port again. There is no receive interrupt, no FIFO, no command parser, no “update ready” mode in the application firmware. The silence I heard was not a protocol waiting for a handshake. It was the absence of any serial code whatsoever.

What the modem lines tell us

Throughout all of this, the CP2104’s modem status lines were consistent:

Line	State	Meaning
CTS	Asserted	MCU is powered and UART is initialized
DSR	Asserted	MCU is ready for communication
CD	Asserted	Active connection (MCU is running)
RI	Deasserted	Normal (no ring indicator function)

The modem lines are asserted because the UART peripheral is initialized (PINSEL0 configures P0.0 as TXD0 and P0.1 as RXD0). The hardware is electrically ready. The firmware just never uses the receive side.

Why the silence made sense

The reason I heard nothing at 115200 baud is that the MCU transmits at 9600 baud. At 115200, the single boot string would have arrived as garbage — a few mangled bytes easily lost in the noise of the CP2104 powering up. Even at the correct baud rate, the boot message is 34 characters sent once at power-on. If the serial monitor was not open and listening at the exact moment AC power was applied, the message would have been missed entirely.

The reason I heard nothing in UPDATE mode is that the UPDATE switch has no effect on the LPC2103F. The MCU boots and runs its application firmware identically in both switch positions. The switch only affects the D2-81431’s boot behavior — and the D2-81431 does not talk on UART0.

Implications (corrected)

The firmware update path for the LPC2103F is the ROM ISP bootloader, accessed via JP24 — not through the UPDATE switch and not through any application-level serial protocol. The flash dump page documents how JP24 was discovered and used to extract the 32KB firmware. The firmware update mechanism page explains the two independent update paths for the two processors.