Stlink: STM32F031K6 Nucleo: regressão entre 1.5.0 e 1.6.0 com script de vinculador mínimo

AVISO: Por favor, leia e siga as instruções em # 906 antes de enviar um tíquete. Portanto, certifique-se de que todos os campos estejam preenchidos.

• [x] Fiz um grande esforço para evitar a criação de problemas duplicados ou quase semelhantes

• Programador / tipo de placa: embutido

• Sistema operacional e versão: macOS 15, openSUSE Tumbleweed
• Versão das ferramentas Stlink e / ou hash do git commit: v1.6.0
• Nome da ferramenta de linha de comando Stlink: st-util
• Chip alvo (e placa, se aplicável): STM32F031K6, STM32F103C8T6 (pílula azul), STM32F3DISCOVERY

Esperado / descrição:

Meu problema surgiu ao seguir o tutorial para um script de vinculador mínimo em: https://vivonomicon.com/2018/04/02/bare-metal-stm32-programming-part-1-hello-arm/
O código-fonte para isso também pode ser encontrado em https://github.com/WRansohoff/STM32F0_minimal

O código compila etc sem problemas.
Em seguida, corro st-util e me conecto ao tabuleiro usando arm-none-eabi-gdb main.elf e target extended-remote :4242
Então eu carrego o programa usando load main.elf .

É aqui que o comportamento de v1.5.0 e v1.6.0 diverge.
Na v.1.5.0, o programa pode ser percorrido usando si , e posso entrar no loop e ver r0 sendo incrementado.

Na v.1.6.0, usar si faz com que o contador do programa salte imediatamente para 0xfffffffe e r0 não seja incrementado.
No entanto, às vezes r7 é definido com êxito como 0xdeadbeef .

Eu também fiz isso usando o OpenOCD 0.10.0 e pude percorrê-lo sem problemas.
Devo observar que construí v1.5.0 da fonte usando libusb 1.0.23 e aplicando o patch # 704.

Por favor, deixe-me saber se você precisar de mais informações.