2026-02-23 3:15 PM
I am using CubeCLT v1.18.0 on an Ubuntu host. I recently got a new J-Trace and ran into warnings about the firmware version not being recognized. I traced the root of the problem being the version of `libjlinkarm.so.7` that ships with this version of CubeCLT.
I need to upgrade to a newer version of the library to resolve the warning. I am already using J-Link v8.48 elsewhere, so I plan to follow this guidance from SEGGER to upgrade the so file. Should it be safe to do this upgrade from v7 to v8? I also noticed that SEGGER release v9.20 of J-Link and was considering going to that. I assume that would include a v9 so. Would that be safe to go to as well?
I have a logistical question regarding how ST manages the shipped version of libjlinkarm. It looks like CubeProgrammer specifically expects `libjlinkarm.so.7`. Is there a particular reason for expecting that fixed version name? For me, it would be preferable to expected `libjlinkarm.so` so that I could symlink it to any version I would like (rather than having a symlink for so.7 that points to so.8).
2026-03-05 4:12 AM
Thanks for reaching out,
> Is there a particular reason for expecting that fixed version name?
Main reason is the fact that the tool was validated with libjlinkarm.so.7 and not libjlinkarm.so.8 or any other version. You can imagine that there are validation efforts that need to be done for STM32CubeProgrammer to support multiple versions (Since the libraries are not the same).
With that being said, the request to support multiple versions is already logged internally to our development team (Internal tracking number: 196537) and will be studied ASAP.
Hope this answers your questions.
Aziz