Xingce Hello-FPGA Frame Grabber Firmware Onboard Upgrade

Xingce Hello-FPGA Frame Grabber Firmware Onboard Upgrade

Illustrated Operation Guide

Chongqing Xingce Electronic Technology Co., Ltd. (Hello-FPGA) · Oct 2026

For ImgGrab V1.3.9 and above · Fully offline · Dual-partition fallback, no bricking risk

1. Overview

The firmware of Hello-FPGA high-speed frame grabbers implements core functions including device interface, data transmission and multi-camera trigger synchronization, which requires iterative updates. Traditional updates require JTAG programmers, Vivado projects and on-site engineers. Failed flashing may force the board to be returned for repair, which brings high cost for production lines with dozens of grabbers installed.

The onboard firmware upgrade function is integrated into ImgGrab. No extra hardware or internet connection is required. The whole update takes minutes following on-screen prompts with built-in fallback protection. This guide walks through the complete workflow with screenshots, and explains its underlying implementation and safety design.

2. Upgrade Workflow

This chapter describes the full procedure from opening the panel to cold boot activation with screenshots.

2.1 Main Panel Overview

Access the tool via Help → Firmware Upgrade in ImgGrab. The panel is divided into four zones for clear visibility of device info, status, firmware options and logs: the left device list shows all local Xingce grabbers and simulator cards; the center panel displays manufacturer, model, firmware version, serial number, hardware revision, firmware status and capabilities; the right section lists compatible firmware releases with operation buttons; the bottom log area records all detection and upgrade steps.

Two extra entries are available under the Help menu: Download Latest Firmware opens the official firmware download page (img-grab.com/jszc) in your default browser. If your local firmware library lacks the target version, download the package and extract it into the firmware folder under the installation directory for automatic recognition. This URL is configurable for private intranet deployment. Flash Diagnostics reads the on-board flash chip status, detailed in Section 3.2.

Firmware upgrade main panel

2.2 Automatic Firmware Status Detection

Manual version comparison is not required. About 3 seconds after ImgGrab launches, a background scan reads firmware fingerprints of all connected devices and compares them against the firmware library. A badge reminder appears at the entry when updates are available, without interrupting active acquisition. Three status types are supported:

If the device model is not found or the version cannot be parsed, the status will also show Update available, but no automatic firmware recommendation will be provided. Manual firmware selection is needed. The log prints the comparison basis including current version, available releases and conclusion for verification.

2.3 Firmware Selection: Update vs Install

After selecting a device, compatible firmware packages for this model are automatically filtered and matched. If your target version is missing, open the download page via Help → Download Latest Firmware as described in 2.1.

Firmware selection list with operation buttons

Two button types are provided with different definitions: Update means the firmware maintains the same device capability for regular upgrade. Install means it changes the board capability (e.g. data stream topology). A strong confirmation dialog pops up before execution to avoid unintended changes. For boards supporting multiple capability modes (e.g. single-stream 1X1Y, dual-stream 1X2YE), the software recognizes the hardware capability and triggers special alerts for cross-capability switching.

2.4 Pre-upgrade Confirmation

Click Update or Install to open the confirmation dialog showing key information: version change, board model & serial number, target partition, image size, estimated duration and capability change notice. Check "I acknowledge the risks" to proceed. This is a safety guardrail: firmware flashing is irreversible, so all parameters and risks are presented clearly to prevent mis-operation.

Upgrade confirmation dialog

2.5 Upgrade Execution & Progress

Before erasure, the software runs a checklist of safety validations: device readiness, model matching, image integrity, size compliance and board temperature. All check results are logged in real time. Erasure and programming start after passing all checks, with progress dialog showing current phase, percentage, write speed and remaining time.

Upgrade in progress: validation checklist + progress / speed / ETA

Do NOT power off, close the window or operate this grabber during upgrade. Cancel is available during erasure. Cancel is temporarily disabled only during the final readback verification phase for data integrity protection, just wait for this step to finish.

2.6 Upgrade Completion & Cold Boot

After successful readback verification, a pop-up confirms firmware flashing and gives clear instructions. Power off the host completely, wait several seconds then power on (cold boot) instead of simple software restart. PCIe grabbers require full power cycle for re-enumeration, so the new firmware loads only after cold boot. This is the common reason users find no change after upgrade.

Upgrade succeeded, cold boot reminder

3. Auxiliary Tools

Two practical on-site tools are integrated in the same panel besides firmware upgrade.

3.1 Device Information Programming

Serial number, model, hardware revision, production date and description can be written into the on-board EEPROM directly. Previously this required a dedicated tool. The same communication channel used for firmware upgrade is reused. Pre-filled existing values are loaded for review and modification before delivery or repair, with format hints for each field.

Device info writing dialog

3.2 Flash Diagnostics

For repeated upgrade failures or tricky issues, the built-in Flash Diagnostics reads flash model, capacity, partition address, JEDEC ID and bus status to help distinguish software faults from hardware problems for faster after-sales support.

Flash diagnostic report

4. Working Principle & Safety Design

The above covers user-facing operations. This section explains the reliability design for this risky flashing process.

4.1 Firmware Library Structure & Naming Rules

Firmware packages are released together with ImgGrab under the installation firmware folder, supporting offline usage. The software automatically scans and parses the library following fixed rules:

Folder structure: Organized by /[_]/; .bin is the update partition image, and the golden/ subfolder contains full factory images;

File name embeds full metadata. Example: HelloFPGA_PCIe_1004_C4_1X2YE_HW_REV_1_FW_REV_93_20260906_1607.bin. It parses model (1004), capability (C4_1X2YE, 4-channel dual-stream), hardware revision (HW_REV_1), firmware revision (FW_REV_93 = V1.3.5) and build timestamp.

Version comparison uses numeric segment comparison (split x.y.z into integers, pad missing segments with zero), avoiding string comparison bugs such as 1.10.0 < 1.9.0.

4.2 Version Evaluation & Recommendation

Besides the three status types in 2.2, the evaluator decides whether full-chip flashing is required, following these rules:

Factory / first-program devices (version ≤ 0.0.1, no dual partition) are marked for full-chip flashing, preferring full factory golden images;

Same-capability priority: For known-capability boards, only the latest stable release with matching capability is recommended;

Unknown capability protection: Manual selection is forced for unknown capability or mixed capability packages to prevent false recommendation;

Cross-capability upgrade: Triggers strong confirmation. Extended capability can override basic capability; reverse downgrade is treated as incompatible.

4.3 Upgrade Pipeline Implementation

The upgrade engine runs as a state machine in a background thread. It triggers recovery, logging and guidance on any failure. Each phase is timed independently for performance analysis and remote troubleshooting.

The "critical region last" rule is an atomic safety design. If power loss or cancel happens mid-process, the primary image header remains intact so the old firmware can still boot.

4.4 SPI Flash Read/Write & Reliability

Firmware is stored on SPI NOR Flash. The same driver supports two densities. JEDEC ID is read at runtime to auto-detect chip type (128Mb / 16MB and 256Mb / 32MB), then determine capacity, partition size and offset without hardcoding. Multiple fault tolerance mechanisms are implemented for long-term field operation:

High-address addressing: Extended Address Register (EAR) is enabled automatically for high flash addresses, with write-enable readback check to prevent address corruption;

Transient retry: Auto retry for sector erase/program failures (max 3 attempts). SPI link reset is executed before retry when needed to absorb power fluctuation and temporary link error;

Fine-grained logging: Trace points are placed at status polling, address setup, transmit/receive and all potential failure points.

4.5 Dual Partition & Fallback Recovery

Flash is split into Golden Factory Partition and Update Partition. Normal onboard upgrade only writes the Update partition. Golden partition is write-protected and untouched in standard workflow. Based on FPGA Multiboot, the hardware automatically falls back to Golden partition if the new firmware fails to boot. This hardware guarantee ensures the board remains usable even after a failed upgrade.

Full-chip flashing (advanced mode) overwrites the Golden partition with extra restrictions: explicit unlock of Golden write protection plus double confirmation. If interrupted during full-chip flashing, keep power on and restart recovery immediately, DO NOT power off, otherwise configuration failure at address 0 may brick the board. Standard upgrade never touches Golden and can safely fallback after cold boot.

4.6 Concurrency, Robustness & Logging

Thread isolation: Flashing runs in background thread with exclusive register access. UI avoids register access during upgrade to eliminate race condition, while keeping responsive;

Single instance lock: Process-level atomic lock ensures only one upgrade task runs at once. "Device busy" is returned for duplicate requests. Upgrade grabbers sequentially;

Crash protection: Silent detection and upgrade engine are wrapped by exception handling. Native exceptions are captured and converted into error codes and logs, without crashing software or disrupting acquisition;

Cooperative cancel: Cancel is controlled by global flag and responds at sector boundaries during erasure. Cancel is blocked in readback phase for data safety;

Full trace logging: Logs are written at INFO/WARN/ERROR levels into log/[date]/FirmwareUpdater.log. Serial number, model, old/new firmware version, image SHA-256, target partition and phase timestamps are recorded for fast after-sales diagnosis.

4.7 Summary of Safety Mechanisms

Four layers of protection are implemented:

Pre-flight health check: Device readiness, model match, image integrity, size and temperature are validated. Upgrade aborts if any check fails;

Double checksum validation: SHA-256 integrity check before write, and full readback comparison after write. Only exact match marks success;

Recoverable interruption: Auto retry for transient power/link error; critical header is written last so old firmware often survives power loss or cancel;

Final hardware fallback: Dual-partition Multiboot recovery. Cold boot restores the factory golden image and prevents bricking.

5. Troubleshooting & FAQ

5.1 Fault Reference Table

5.2 Frequently Asked Questions

Can the board survive a power cut during upgrade? Yes. Golden partition fallback is available. Cold boot loads the old working firmware without bricking. You can retry the upgrade afterwards.

Can I upgrade without internet access? Yes. Firmware bundles are shipped with ImgGrab, fully offline.

Will camera parameters or software settings be erased? No. Only board firmware is replaced. Camera and software configurations remain unchanged.

Is cold boot mandatory? Yes. PCIe devices require full power cycle for re-enumeration. Soft restart often fails to load new firmware.

Can I upgrade multiple grabbers in parallel? Upgrade one grabber at a time to avoid concurrency errors, this is the stable practice.

6. Supported Devices & Firmware Acquisition

This workflow applies to PCIe-1004, 1006, 2004, 3004 frame grabbers, ZU19EG-1004 embedded platform, JetKU series, and PCIe-1005, 2005, 3005, 4005 simulator cards, sharing the same upgrade panel.

Every ImgGrab installer contains the latest firmware for all released models. If newer firmware is released after your installer, open the download page via Download Latest Firmware in the upgrade panel, extract the package into the firmware folder and the software will detect it automatically.