FERS Upgrader

Firmware upgrade tool for the CAEN FERS-5200 family: the A/DT5202–A/DT5205 front-end boards and the DT5215 and DT5216 concentrators.

One tool replaces the scattered set that used to be needed — the Janus/FERSlib upgrade command, the DT5215 web interface, pci32_blhost, the CAEN A4818 toolbox. It talks every protocol natively, over Ethernet, over USB and through a TDlink fibre chain, from a graphical interface or from the command line.

Install

Every release is published on the Nuclear Instruments download portal:

https://downloads.nuclearinstruments.eu/packages/fers-upgrader/

Windows

Download FERSUpgrader-setup-<version>-amd64.exe from the portal and run it. It installs the graphical interface, the fersup CLI and pic32probe into C:\Program Files\Nuclear Instruments\FERS Upgrader, and creates Start menu and desktop shortcuts.

Windows 10 or later, 64-bit. The installer pulls in the Microsoft WebView2 runtime if it is not already present (it ships with Windows 11 and with any recent Edge).

If you cannot install software on the machine, take fers-upgrader-<version>-windows-amd64.zip instead and unpack it anywhere — the executables are self-contained, with no DLL to copy alongside.

Linux — apt

The recommended route on Debian and Ubuntu. Once the Nuclear Instruments apt repository is configured on the machine:

sudo apt update
sudo apt install fers-upgrader

Packages are published for Ubuntu 22.04 (jammy) and 24.04 (noble), and Debian 12 (bookworm) and 13 (trixie), amd64. The package sets up the udev rule that lets you reach the hardware over USB without root, and adds FERS Upgrader to the applications menu.

If you have not configured the repository yet, follow the instructions on the package page, or download the .deb from there and install it directly:

sudo apt install ./fers-upgrader_<version>_noble_amd64.deb

Linux — portable

For any other distribution, fers-upgrader-<version>-linux-amd64.tar.gz contains the three executables:

tar xzf fers-upgrader-<version>-linux-amd64.tar.gz
./fersupgrader-gui

It needs libusb-1.0, and the GUI additionally needs GTK 3 and WebKit2GTK — all three are present on any normal desktop install. You will have to add the udev rule yourself (see USB permissions).

Quick start

Graphical interface

1. Launch FERS Upgrader from the applications menu (or run fersupgrader-gui).
2. Add your hardware: let the tool discover boards on the network, or type in a concentrator's address.
3. Drop in the firmware files — the tool identifies each one by content and tells you which devices it applies to.
4. Pick the devices to upgrade and start. Progress and a full log are shown as it runs, and the log can be exported.

Firmware files are never matched by extension: .niu alone is ambiguous between two unrelated formats, so the tool always looks inside the file.

Command line

fersup --help                       # every subcommand and flag
fersup discover                     # find boards and concentrators
fersup inspect firmware.ffu         # what is this file, and what does it fit?
fersup upgrade -c Janus_Config.txt  # run the upgrade described by a config file

fersup reads the same Janus_Config.txt files as Janus, including Open[n] board declarations, Load includes and FiberDelayAdjust directives, which it preserves verbatim so the file stays usable by Janus itself. On top of those it understands a few extra directives that Janus ignores:

What can be upgraded, and how

Worth knowing:

• The MCU of a board can only be upgraded over direct Ethernet. Its PIC32 bootloader speaks UDP at a fixed address and cannot be reached through a concentrator.
• Boards on the same TDlink chain are upgraded strictly one after another. Different chains, and directly connected boards, go in parallel.
• A TDlink upgrade is never followed by an automatic reboot or power cycle — that decision is always left to you.
• A board reporting FPGA revision 0 has no valid application firmware. That is a normal, upgradable state, not an error.

Firmware file formats

Hardware access

USB permissions (Linux)

The .deb package installs this automatically. If you are using the portable archive, create /etc/udev/rules.d/99-fers-upgrader.rules:

SUBSYSTEM=="usb", ATTR{idVendor}=="04d8", ATTR{idProduct}=="0053", MODE="0666", TAG+="uaccess"
SUBSYSTEM=="usb", ATTR{idVendor}=="21e1", ATTR{idProduct}=="0016", MODE="0666", TAG+="uaccess"

then sudo udevadm control --reload-rules && sudo udevadm trigger, and unplug and replug the device. Without it, USB operations fail with a permission error unless you run as root.

04d8:0053 is a FERS board on direct USB; 21e1:0016 is a DT5216.

USB driver (Windows)

USB access goes through WinUSB. If a device shows up in Device Manager but FERS Upgrader does not see it, bind the WinUSB driver to it with Zadig: pick the device, select WinUSB, and click Replace Driver. Ethernet and the DT5215 HTTP path need no driver at all.

Firewall (Windows)

Discovery and the MCU upgrade use UDP. Allow fersupgrader-gui, fersup and pic32probe through Windows Defender Firewall on the private profile, which is normally what a direct board connection is classified as.

When the MCU upgrade will not start

This is the one upgrade that needs a physical power cycle, and the one worth knowing a procedure for.

The FERS application firmware has no "reboot into bootloader" command, so the PIC32 bootloader is only reachable in the 4–6 second window right after a reset, at the hardcoded address 192.168.50.2:6234. That address — and the MAC behind it — is the same on every board, so never power-cycle two boards at once.

When the tool reports that the bootloader never answered, run pic32probe before suspecting the board. It sends nothing but a status request, in a loop, and prints every outcome:

pic32probe                        # 192.168.50.2:6234, every 100 ms, until Ctrl-C
pic32probe -every 50ms -for 2m    # poll faster, give up after two minutes
pic32probe -quiet                 # print only changes of state
pic32probe -local 192.168.50.50:0 # force a specific source address

1. Start it with the board powered off. Every line should read silence. Lines reading ERROR print the OS error code; on Windows 10054 and 10065 are ICMP bounces and are harmless.
2. Read the two header lines about the source address. You want probe is pinned to source 192.168.50.50 (interface "..."). A WARNING there means this PC has no address on 192.168.50.0/24 and nothing will ever reach a board in bootloader mode — give the network interface a static address on that subnet. A NOTE that the routing table disagrees is normal and already handled.
3. Power-cycle the board. Within a second or two a run of ANSWER bootloader x.y lines must appear. That is proof the upgrade path works — and the probe holds the bootloader open, so the board waits there instead of jumping to the application and you can start the real upgrade straight away.
4. If step 3 prints nothing but ping 192.168.50.2 answers, the remaining suspects are the Windows firewall and a second board answering on the same address.

The closing summary counts everything that happened and ends with a verdict naming what to check next. The same counters are reported through the GUI's progress messages, so a failed upgrade in the field already tells you whether anything was received at all.

Configuration profiles

A profile is just a Janus_Config.txt-compatible file with a metadata block in leading comments. Save one from the GUI, or hand it to fersup -c, and the same set of devices and firmware files is reproduced exactly.

Support and development

• Package page and downloads: https://downloads.nuclearinstruments.eu/packages/fers-upgrader/
• Release notes: CHANGELOG.md
• Building from source, architecture and tests: docs/DEVELOPMENT.md
• Cutting a release: docs/RELEASE.md
• Protocol notes: docs/protocols.md

Nuclear Instruments s.r.l. — info@nuclearinstruments.eu