B210: all-FF EEPROM serial prevents Windows enumeration after FX3 firmware load #951

Summary

A B210 became inaccessible on Windows immediately after loading FX3 application firmware. The problem was resolved by repairing an EEPROM serial field containing nine 0xFF bytes.

A full diagnostic firmware build bypassing only the EEPROM serial read worked over USB 3.0. After repairing the serial field, unmodified stock firmware also worked.

The cause of the original EEPROM contents is unknown. This report concerns handling of uninitialized serial data, not a claim that UHD erased the field.

Environment

• USRP B210, PCB label 156229B-01L, Ettus Research branding
• Windows 11, OS version reported as 10.0.26200.0
• UHD 4.11.0.0-release
• Additional host test: Radioconda UHD 4.8.0.0-release
• Ettus WinUSB driver version 4.9.0.0
• Diagnostic firmware source: tag v4.8.0.0, commit prefix 308126a
• Diagnostic build: Cypress FX3 SDK 1.3.5, SDK ARM GCC 4.8.1
• Final successful stock firmware compatibility: 8.0
• Final successful FPGA compatibility: 16.0

The installed UHD 4.8 and 4.11 FX3 firmware files were identical. A genuinely different official image from UHD 3.15 LTS was tested separately and also failed.

Observed behavior

Before application firmware loading, the device appeared as 2500:0020 with Windows status Started.

Running:

& "F:\UHD\lib\uhd\utils\b2xx_fx3_utils.exe" -Q

produced:

Device opened (VID=0x2500,PID=0x0020)
B2xx detected... Control of B2xx granted...

Loading firmware
[INFO] [B200] Loading firmware image: ...\usrp_b200_fw.hex...
Cannot open device

Windows then reported:

Code 10 / CM_PROB_FAILED_START
Problem Status: 0xC000000E

uhd_find_devices.exe found no devices. Pressing S700 restored initial accessibility.

Diagnostic evidence

1. All 182,268 data bytes of the stock FX3 firmware were written to RAM and read back correctly before execution.
2. The SDK CyBootProgrammer.img ran successfully from RAM and enumerated as 04B4:4720.
3. Installing the B2xx bootloader, with UHD-style metadata migration and complete EEPROM read-back verification, did not resolve the failure.
4. Forcing USB 2.0 in otherwise full firmware did not resolve it.
5. Full firmware with only the serial descriptor workaround below worked over both USB 2.0 and USB 3.0:

In firmware/fx3/b200/firmware/b200_main.c:

- const uint8_t *serial_string = get_serial_string_descriptor(&eeprom_read);
+ const uint8_t *serial_string = common_dev_serial_desc;

SuperSpeed was re-enabled for the final diagnostic test. FPGA loading, radio initialization and both register loopback tests passed.

EEPROM finding and repair

The serial field contained:

FF FF FF FF FF FF FF FF FF

These contents were present in the original EEPROM backup taken before our bootloader installation.

After migration to the revision-1 layout, the nine-byte serial field was at 0x7F25, consistent with EEPROM_REV1_SERIAL_ADDR and EEPROM_SERIAL_LENGTH in common_const.h.

We replaced it with the confirmed board serial 30F7D7C:

33 30 46 37 44 37 43 00 00

The complete 64-byte EEPROM page was preserved except for the serial field, written, and followed by a full 32 KB read-back comparison. Only offsets 0x7F25..0x7F2D changed during serial repair.

This serial and address are specific to the device/layout in this report.

Validation with unmodified firmware

$env:PATH = "F:\UHD\bin;" + $env:PATH

& "F:\UHD\lib\uhd\utils\b2xx_fx3_utils.exe" `
  --load-fw "F:\UHD\share\uhd\images\usrp_b200_fw.hex" --speed

& "F:\UHD\bin\uhd_find_devices.exe"

& "F:\UHD\lib\uhd\utils\b2xx_fx3_utils.exe" -Q

& "F:\UHD\bin\uhd_usrp_probe.exe" `
  --args "type=b200,serial=30F7D7C" --init-only

Results:

Firmware loaded
Currently operating at USB 3
serial: 30F7D7C
product: B210
type: b200
Bootloader is present
Register loopback test passed
Register loopback test passed
Actually got clock rate 16.000000 MHz.

The successful stock firmware file had SHA-256:

cc8e4bc968d91d1a67c63871ce5b2c1613c49676fe363bf2f6e336059899ae5c

No RF transmission or sustained RX/TX streaming test was performed.

Expected behavior / proposed improvement

Could the FX3 firmware validate the EEPROM serial field and handle erased/uninitialized data explicitly?

For example, an all-0xFF field could trigger a deterministic fallback USB serial or another recovery mechanism that leaves the device accessible and provides an actionable diagnostic.

I have not captured a USB protocol trace, so I cannot identify the exact Windows rejection mechanism. However, bypassing the serial read and then repairing only that field both eliminated the failure.

I would appreciate guidance on whether this is a known condition and what fallback behavior would be appropriate.