mbed-tools
mbed-tools copied to clipboard
ARMmbed
Display "firmware update available" when listing devices with available updates
Is your feature request related to a problem? Please describe. Without this, we can get issues like in ARMmbed/mbed-os#4301
Describe the solution you'd like Display a "firmware update available" message when the device's STLInk or DAPLink version is out of date.
We'd like to avoid hardcoding what the latest firmware available is. We'd also like to avoid hardcoding what "an update that contains a critical fix" is.
Possible sources of information about the latest DAPLink firmware versions available per board include: The DAPLink website, the DAPLink repo's release tags, or reading some file within a DAPLink release. Which version of DAPLink to use on which board may be board specific, but it might also be that any version will work.
We'll need to determine how to find the latest STLink version, too. For ST boards, all STLink versions are compatible with all boards (old boards never stop getting STLink firmware upgrades, even after they are deprecated or discontinued).
Describe alternatives you've considered Display a warning about an STLInk or DAPLink version mismatch when there is an update available that is known to contain a critical fix.
Additional context From @jeromecoutant: "This is surely not the perfect place to do it, but this is my first proposition: https://github.com/ARMmbed/mbed-tools/commit/c4101506701355a10cb3b0159ab3071275ef7ec1"
"This is surely not the perfect place to do it, but this is my first proposition: c410150"
Thx @Patater I think this proposition is OK for a first step and it could be improved later. About hardcoded version number, I don't see yet any better idea... but it has to be updated not at each new FW version, but maybe at each critical FW, so it should be not "often"...
Do we have ideas how one can tell programmatically if a release is "critical" or not?
it has to be updated not at each new FW version
What is the reason for that? Why not every new version?
New version could be "only" to add new MCU support.
FYI: https://www.st.com/resource/en/release_note/dm00107009-firmware-upgrade-for-stlink-stlinkv2-stlinkv21-and-stlinkv3-boards-stmicroelectronics.pdf
Can we not add the latest version to the platform database on os.mbed.com? If we need to update something periodically to bump a version it should be a database and not our code. I'm don't like the idea of hardcoding the firmware versions in the tool. We should ideally be trying to consolidate the "mbed target" information in one place (the database) rather than adding another source of truth just to cover a specific edge case. I'd also prefer to implement this once and not follow a "patch now and improve it later" approach, as it's possible we won't have time to change it later.
My experience of waiting for mbed-os database update makes me think that it is better to have a patch first :-)
I agree with Jerome, it's much easier to handle the tools versions in this tool. Note we don't currently have the corresponding artefacts in os.mbed.com to handle interface versions.
Can we put this information into targets.json if not the online database? The tool isn't really supposed to have any data in it itself, as this makes it difficult to use different tool version with different Mbed OS versions.
@Patater there is no direct link between mbedtools and targets.json. We can call 'mbedtools detect' from anywhere
We could add another field to the online JSON database to list the interface versions, couldn't we? I'm not sure which artefacts we need to handle interface versions. We just need to update the JSON schema and add the information, right?
We feel that hardcoding the information in the tool would be a mistake. Part of the reasoning is because using the database is a more maintainable solution in the long run. It's more time intensive to update the python code, raise a PR, get it to pass CI and wait for a release to be made (think of mbedls target additions) than to add a value to the online database. The tool will look online for the latest version of the database, so it will pick up the changes in the field, meaning we don't have to cut another release of mbed-tools whenever there's an update to the database. Because we won't need to make a tools release every time there's a db update we benefit our users, as they would always be notified when they need to update the firmware on their board. If we hardcode this information in the tool the user would have to update the tool to be notified that the firmware version is out of date, which could cause confusion/issues.
If we need to wait a long time to get updates in the database (although it does seem to be updated quite often) we should fix that process so there's minimal latency between a new firmware release and a database update.
@rwalton-arm thanks for the details. Using data from a database would initially make sense. IMO the main problem is the process to update the online database, which is very obscure and restricted to few Arm colleagues. On the other side, a PR could be raised and reviewed openly by anyone.
@donatieng please share your view when you have chance. Thanks
Agreed that the database solution definitely makes sense - today the API returns an array of supported interface firmwares (such as "interface_firmware":["ST-Link"]). @jeromecoutant is there a ST-provided API we could use to retrieve the latest ST-Link version? Alternatively, I've looked at our API's code and we would need a separate API endpoint to provide this versioning info.
Also I had a look at the ST-Link release cycle and it seems to be bi-annual (one in Jan, one in May). So even having some kind of minimal static API should be easy to create and maintain (could be a repo using GitHub pages with one JSON file in it :D).
@jeromecoutant is there a ST-provided API we could use to retrieve the latest ST-Link version?
No... I agree this information could be part of https://os.mbed.com/api/v4/targets
Thanks for confirming Jerome - I'll discuss with the team to see what we can do there. It feels to me like it'd be worth looking at a separate API endpoint (something like https://os.mbed.com/api/v4/interfaces or similar).
(could be a repo using GitHub pages with one JSON file in it :D).
Maybe I could create this json file in https://github.com/ARMmbed/mbed-os/tree/master/targets/TARGET_STM/tools
Then when a new mbed-tools is released, it reads ST-Link version in the mbed-os master branch?