Stlink: STM32F031K6 Nucleo : Régression entre 1.5.0 et 1.6.0 avec un minimum de script de liaison

AVIS : Veuillez lire et suivre les instructions du n° 906 avant de soumettre un ticket. Veuillez donc vous assurer que tous les champs sont remplis.

• [x] J'ai fait de sérieux efforts pour éviter de créer un problème en double ou presque similaire

• Type de programmateur/carte : Intégré

• Système d'exploitation et version : macOS 15, openSUSE Tumbleweed
• Version des outils Stlink et/ou hachage git commit : v1.6.0
• Nom de l'outil de ligne de commande Stlink : st-util
• Puce cible (et carte le cas échéant) : STM32F031K6, STM32F103C8T6 (pilule bleue), STM32F3DISCOVERY

Attendu/description :

Mon problème est survenu en suivant le didacticiel pour un script d'éditeur de liens minimal sur : https://vivonomicon.com/2018/04/02/bare-metal-stm32-programming-part-1-hello-arm/
Le code source pour cela peut également être trouvé sur https://github.com/WRansohoff/STM32F0_minimal

Le code compile etc sans aucun problème.
J'exécute ensuite st-util et je me connecte à la carte en utilisant arm-none-eabi-gdb main.elf et target extended-remote :4242
Ensuite, je charge le programme en utilisant load main.elf .

C'est là que les comportements des v1.5.0 et v1.6.0 divergent.
Dans la version 1.5.0, le programme peut être parcouru en utilisant si , et je peux entrer dans la boucle et voir r0 être incrémenté.

Dans la version 1.6.0, l'utilisation de si fait passer immédiatement le compteur du programme à 0xfffffffe , et le r0 n'est pas incrémenté.
Cependant, parfois r7 est correctement défini sur 0xdeadbeef .

Je l'ai également fait en utilisant OpenOCD 0.10.0 et j'ai pu le parcourir correctement.
Je dois noter que j'ai construit la v1.5.0 à partir des sources en utilisant libusb 1.0.23 et en appliquant le patch #704 .

S'il vous plaît laissez-moi savoir si vous avez besoin de plus d'informations.