Stlink: STM32F031K6 Nucleo: регрессия между 1.5.0 и 1.6.0 с минимальным скриптом компоновщика

ВНИМАНИЕ: пожалуйста, прочтите и следуйте инструкциям в # 906 перед отправкой заявки. Поэтому убедитесь, что все поля заполнены.

• [x] Я приложил серьезные усилия, чтобы избежать дублирования или почти аналогичной проблемы.

• Тип программатора / платы: Встроенный

• Операционная система и версия: macOS 15, openSUSE Tumbleweed
• Версия инструментов Stlink и / или хеш фиксации git: v1.6.0
• Имя инструмента командной строки stlink: st-util
• Целевой чип (и плата, если применимо): STM32F031K6, STM32F103C8T6 (синяя таблетка), STM32F3DISCOVERY

Ожидается / описание:

Моя проблема возникла, когда я следовал руководству по минимальному сценарию компоновщика по адресу: https://vivonomicon.com/2018/04/02/bare-metal-stm32-programming-part-1-hello-arm/
Исходный код для этого также можно найти на https://github.com/WRansohoff/STM32F0_minimal.

Код компилируется и т. Д. Без проблем.
Затем я запускаю st-util и подключаюсь к плате с помощью arm-none-eabi-gdb main.elf и target extended-remote :4242
Затем я загружаю программу, используя load main.elf .

Здесь поведение v1.5.0 и v1.6.0 расходится.
В версии 1.5.0 программа может быть запущена с использованием si , и я могу войти в цикл и увидеть, как r0 увеличивается.

В v.1.6.0 при использовании si счетчик программы немедленно переходит на 0xfffffffe , а значение r0 не увеличивается.
Однако иногда r7 успешно устанавливается в 0xdeadbeef .

Я также сделал это, используя OpenOCD 0.10.0, и смог пройти через это нормально.
Следует отметить, что я собрал v1.5.0 из исходников, используя libusb 1.0.23 и применив патч # 704.

Пожалуйста, дайте мне знать, если вам понадобится дополнительная информация.