CODESYS Control for Raspberry Pi 5 - "Hardware version or firmware version not supported" on Rev 1.1, persists across multiple runtime versions and OS images
I'm trying to run CODESYS Control for Raspberry Pi SL on a Raspberry Pi 5, and the runtime consistently fails to start with the following error when launched manually:
ooops... this runtime was built for RASPBERRYPI. Hardware version or firmware version not supported! (-18, 0x00000BB8, 0xFFFFFFFB)
Hardware:
Raspberry Pi 5 Model B Rev 1.1
Revision code: d04171
CPU: aarch64, BCM2712
Serial number is correctly exposed via /proc/cpuinfo and /proc/device-tree/serial-number
/proc/device-tree/model correctly reports "Raspberry Pi 5 Model B"
What I've tried (all resulting in the same error):
CODESYS Control for Raspberry Pi SL 4.11.0.0 (SDK 3.5.19.61) β the version that introduced Pi 5 support
CODESYS Control for Raspberry Pi SL 4.21.0.0 (SDK 3.5.22.20) β latest available
Raspberry Pi OS Bookworm (64-bit) with kernel 6.12.93+rpt-rpi-2712 (June 2026 build)
Fresh install on Raspberry Pi OS Bookworm (64-bit) with an older image from November 24, 2025 β same error, ruling out a kernel-version regression
Bootloader/EEPROM confirmed up to date (rpi-eeprom-update reports "up to date")
Clean purge and reinstall of the codesyscontrol package each time (verified via dpkg -l, no leftover files)
Verified /etc/codesyscontrol/3S.dat correctly symlinks to /etc/codesyscontrol/3S_aarch64.dat
The service starts (systemctl status briefly shows active (running) with a real PID under /opt/codesys/bin/codesyscontrol.bin), but crashes shortly after and the process disappears β port 11740 never opens.
Since this happens identically across two different runtime versions and two different OS images (5+ months apart), it doesn't seem to be a kernel/firmware timing issue. Could this be specific to the Rev 1.1 board revision, or is there a known issue with the hardware detection logic in the SL runtime that I should be aware of?
Happy to provide full debug logs (-d flag output) or journalctl output if useful.
Thanks in advance!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm trying to run CODESYS Control for Raspberry Pi SL on a Raspberry Pi 5, and the runtime consistently fails to start with the following error when launched manually:
ooops... this runtime was built for RASPBERRYPI. Hardware version or firmware version not supported! (-18, 0x00000BB8, 0xFFFFFFFB)
Hardware:
Raspberry Pi 5 Model B Rev 1.1
Revision code: d04171
CPU: aarch64, BCM2712
Serial number is correctly exposed via /proc/cpuinfo and /proc/device-tree/serial-number
/proc/device-tree/model correctly reports "Raspberry Pi 5 Model B"
What I've tried (all resulting in the same error):
CODESYS Control for Raspberry Pi SL 4.11.0.0 (SDK 3.5.19.61) β the version that introduced Pi 5 support
CODESYS Control for Raspberry Pi SL 4.21.0.0 (SDK 3.5.22.20) β latest available
Raspberry Pi OS Bookworm (64-bit) with kernel 6.12.93+rpt-rpi-2712 (June 2026 build)
Fresh install on Raspberry Pi OS Bookworm (64-bit) with an older image from November 24, 2025 β same error, ruling out a kernel-version regression
Bootloader/EEPROM confirmed up to date (rpi-eeprom-update reports "up to date")
Clean purge and reinstall of the codesyscontrol package each time (verified via dpkg -l, no leftover files)
Verified /etc/codesyscontrol/3S.dat correctly symlinks to /etc/codesyscontrol/3S_aarch64.dat
The service starts (systemctl status briefly shows active (running) with a real PID under /opt/codesys/bin/codesyscontrol.bin), but crashes shortly after and the process disappears β port 11740 never opens.
Since this happens identically across two different runtime versions and two different OS images (5+ months apart), it doesn't seem to be a kernel/firmware timing issue. Could this be specific to the Rev 1.1 board revision, or is there a known issue with the hardware detection logic in the SL runtime that I should be aware of?
Happy to provide full debug logs (-d flag output) or journalctl output if useful.
Thanks in advance!
you need to wait for the 4.22.0.0 release which will fix this problem
Last edit: eschwellinger 4 hours ago
when is the releaseof the 4.2.0.0