USB identity and firmware loading¶

The F-X35 scanners are Cypress/Anchor EZ-USB FX2 devices. On power-on they come up running a bootstrap firmware and must be handed a second-stage image over USB before they operate as a scanner. The USB identity does not name the model: the model is a property of the internal controllers, discovered later over the command protocol.

Established from analysis of the OEM Windows driver and firmware loader, and USB captures of the firmware-load sequence, March 2026; firmware file inventory and PICL Plus disassembly added May 2026. OEM file paths below are given relative to a standard Windows install of the Pakon software.

Cold and warm identity¶

State	USB VID:PID	Meaning
Cold (bootstrap)	`0f05:f235`	unloaded family bootstrap; needs firmware
Warm (operational)	`0f05:f135`	operational F-135-family scanner
Warm	`0f05:35f2`	operational F-235
Warm	`0f05:f335`	operational F-335

[DOCUMENTED] 0f05 is the vendor ID across the family; the cold f235 and warm f135 IDs are read from the driver/INF and observed in captures. A consequence worth stating plainly: the USB PID is set by the running firmware, not the physical model. The F-135 and F-135+ present identical cold and warm IDs and cannot be distinguished from USB descriptors; the model is only knowable from the command-protocol presence probes (see ppb-protocol.md). [INFERRED] from the shared identity and the personality mechanism below.

The personality mechanism¶

The word personality gets used for three related things, so this page fixes what each one means and the rest of the reference follows it.

The personality is an 8-byte Cypress C0 boot record, stored at the very start of the boot EEPROM (I2C 0x51):

[0xC0] [vendorId:2] [productId:2] [revision:2] [config]

On an F-135 or F-135+ it reads c0 05 0f 35 f2 07 aa 04, little-endian throughout, so vendor 0f05, product f235, revision aa07. The FX2 bridge silicon reads it at power-up with no host involvement, and it is what makes the scanner cold-enumerate as 0f05:f235 revision aa07.

The boot EEPROM is the chip that record sits on. It is not a synonym for the personality: past the record it holds a ninth byte, 0x02, which is outside the C0 format and is not understood, and then 0xFF for as far as anyone has read. The part is almost certainly a Microchip 24LC64, so 8192 bytes, of which only the first 256 have been read (see per-unit-data-and-safety.md).

The personality key is <productId>_<revision>, so F235_AA07. It is a label the host forms from two fields of the record in order to choose a firmware image. It is not stored anywhere on the scanner.

Every family member cold-enumerates the same way. Once the stage-1 loader is running, the host can ask it for the record with vendor request 0xA9 and wIndex 0, which returns those same 8 bytes and not the ninth ([CONFIRMED on hardware, August 2026] on serial 16402, where the loader's 8 bytes matched the chip's first 8 exactly). That read is how the driver gets the key, and it is not a way to dump the chip; for that see per-unit-data-and-safety.md. The revision distinguishes the model families:

Personality key	Firmware image	Family
`F235_AA05`	`FX35Driver\Pakon5.hex`	F-235
`F235_AA07`	`FX35Driver\Pakon7.hex`	F-135 (and F-135+)
`F235_AA08`	`FX35Driver\Pakon8.hex`	F-335

[DOCUMENTED] from the OEM INF file and the firmware loader source; the FX2 images ship in the driver install directory (FX35Driver\), with a shared bootstrap stage FX35Driver\PknInit.hex. Note that the F-135 and F-135+ share one key (F235_AA07) and therefore one FX2 firmware image: the FX2 is a plain USB-to-bus bridge, and everything model-specific lives behind it on the internal controller boards, which carry their own firmware and are not loaded over USB at power-on. [INFERRED] from the shared personality and the bridge architecture. [CONFIRMED on hardware, August 2026] a real F-135+ cold-enumerates 0f05:f235, and the F-135's Pakon7.hex image (replayed from a firmware-load capture) brings it up as operational 0f05:f135: the Plus and the F-135 use the same FX2 image.

The firmware download¶

The load is the standard FX2 (EZ-USB) sequence, over USB control transfers:

hold the 8051 in reset (write the CPUCS register)
download a bootstrap stage to internal RAM (vendor request 0xA0)
release reset; the bootstrap enables external-RAM writes
read the personality (0xA9) and select the model image
download the main image (internal 0xA0 + external 0xA3 RAM)
reset again to run it; the device re-enumerates as the operational scanner

[DOCUMENTED] from the firmware-load capture and the loader source. The CPUCS register is at 0x7F92 on the older EZ-USB and 0xE600 on the FX2. The bootstrap and main images are Intel HEX files in the OEM package; this reference documents the sequence, not the firmware bytes (see CONVENTIONS.md).

Controller firmware¶

Behind the FX2 bridge, each scanner's controllers run their own firmware, programmed at the factory and not part of the USB power-on load:

Model	Light/CCD	Motor	Notes
F-135	PICL (PL-series, PIC16)	PICM (PM-series, PIC16)
F-135+	PICL+ (NL-series, PIC18)	PICM+ (NM-series, PIC18)	adds TEC, integrated DX
F-235	separate CCD board	separate motor board	dedicated DX board
F-335	separate CCD board	separate motor board	LED illumination, dedicated DX board

[DOCUMENTED] from the OEM firmware readmes (F-X35 COM SERVER\Config\Firmware\, which holds the PIC images: PL/PM for the F-135, NL/NM for the F-135+, and the separate-board prefixes for the larger models). The F-135+ PICL Plus firmware (NL050A.HEX) disassembles as PIC18 (4-byte absolute addressing, config registers at 0x300000), confirming the architecture step up from the F-135's PIC16. [CONFIRMED] by disassembly, May 2026. See scanner-family.md for the full per-model breakdown.

Open questions¶

What the record's configuration byte (0x04) selects is not decoded here, and the byte after the record (0x02) is not understood at all. Only the second of those is outside the C0 format; the first has a defined position in it, whatever its value means on this hardware.
What the boot EEPROM holds past its first 256 bytes. Those 256 have been read: after the record and the byte following it, they are 0xFF. But the part appears to be a Microchip 24LC64, 8192 bytes, so 97% of it has never been read. [CONFIRMED on hardware, August 2026] for the first 256 bytes on serial 16402, with the wValue 0x00A3 select described in per-unit-data-and-safety.md. One unit only, so whether another stores anything there is untested. The separate per-unit EEPROM at 0x52 is documented in calibration.md.