Stlink: STM32F031K6 Nucleo: Regression zwischen 1.5.0 und 1.6.0 mit minimalem Linker-Skript

HINWEIS: Bitte lesen und befolgen Sie die Anweisungen in #906, bevor Sie ein Ticket einreichen. Bitte stellen Sie daher sicher, dass alle Felder ausgefüllt sind.

• [x] Ich habe ernsthafte Anstrengungen unternommen, um ein doppeltes oder fast ähnliches Problem zu vermeiden

• Programmierer/Board-Typ: Eingebaut

• Betriebssystem und Version: macOS 15, openSUSE Tumbleweed
• Stlink-Tools-Version und/oder Git-Commit-Hash: v1.6.0
• Name des Stlink-Befehlszeilentools: st-util
• Zielchip (und ggf. Platine): STM32F031K6, STM32F103C8T6 (Blaue Pille), STM32F3DISCOVERY

Erwartet/Beschreibung:

Mein Problem trat auf, als ich dem Tutorial für ein minimales Linker-Skript unter folgte: https://vivonomicon.com/2018/04/02/bare-metal-stm32-programming-part-1-hello-arm/
Den Quellcode hierfür finden Sie auch unter https://github.com/WRansohoff/STM32F0_minimal

Der Code kompiliert usw. ohne Probleme.
Ich führe dann st-util und verbinde mich mit arm-none-eabi-gdb main.elf und target extended-remote :4242 mit dem Board
Dann lade ich das Programm mit load main.elf .

Hier weichen die Verhaltensweisen von v1.5.0 und v1.6.0 voneinander ab.
In v.1.5.0 kann das Programm mit si schrittweise durchlaufen werden, und ich kann in die Schleife eintreten und sehen, wie r0 inkrementiert wird.

In v.1.6.0 bewirkt die Verwendung von si dass der Programmzähler sofort auf 0xfffffffe springt und r0 nicht erhöht wird.
Manchmal wird r7 jedoch erfolgreich auf 0xdeadbeef .

Ich habe dies auch mit OpenOCD 0.10.0 getan und konnte es gut durchlaufen.
Ich sollte beachten, dass ich v1.5.0 aus dem Quellcode mit libusb 1.0.23 erstellt und den Patch #704 angewendet habe.

Bitte lassen Sie es mich wissen, wenn Sie weitere Informationen benötigen.