Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

STM32F031K6 Nucleo: Regression between 1.5.0 and 1.6.0 with minimal linker script #1064

Closed
1 task done
gcohara opened this issue Nov 4, 2020 · 7 comments · Fixed by #1027
Closed
1 task done

STM32F031K6 Nucleo: Regression between 1.5.0 and 1.6.0 with minimal linker script #1064

gcohara opened this issue Nov 4, 2020 · 7 comments · Fixed by #1027

Comments

@gcohara
Copy link

gcohara commented Nov 4, 2020

NOTICE: Please read and follow instructions in #906 before submitting a ticket. This feature request will be deleted without notice when not enough information is provided! So please ensure that all fields are filled out.

  • I made serious effort to avoid creating duplicate or nearly similar issue

  • Programmer/board type: Inbuilt

  • Operating system and version: macOS 15, openSUSE Tumbleweed

  • Stlink tools version and/or git commit hash: v1.6.0

  • Stlink commandline tool name: st-util

  • Target chip (and board if applicable): STM32F031K6, STM32F103C8T6 (Blue pill), STM32F3DISCOVERY

Expected/description:

My issue arose while following the tutorial for a minimal linker script at: https://vivonomicon.com/2018/04/02/bare-metal-stm32-programming-part-1-hello-arm/
The source code for this can also be found at https://github.com/WRansohoff/STM32F0_minimal

The code compiles etc with no problems.
I then run st-util, and connect to the board using arm-none-eabi-gdb main.elf and target extended-remote :4242
Then I load the program using load main.elf.

This is where the behaviour of v1.5.0 and v1.6.0 diverge.
In v.1.5.0, the program can be stepped through using si, and I can enter into the loop and see r0 being incremented.

In v.1.6.0, using si causes the program counter to immediately jump to 0xfffffffe, and the r0 is not incremented.
However, sometimes r7 is successfully set to 0xdeadbeef.

I have also done this using OpenOCD 0.10.0, and was able to step through it fine.
I should note that I built v1.5.0 from source using libusb 1.0.23 and applying the patch #704 .

Please let me know if you need more information.

@Nightwalker-87
Copy link
Member

Nightwalker-87 commented Nov 4, 2020

Of what hardware-type is your programmer? Please describe it more precisely to complete the set of basic info.
Do later toolset versions work (again)?

@gcohara
Copy link
Author

gcohara commented Nov 4, 2020

I'm using the built in programmers for the Nucleo and Discovery boards, which I believe are ST-Link v2, and a ST-Link v2 usb programmer for the blue pill.

It doesn't work on v1.6.1 - this is the version I was using on macOS, while on openSUSE I was on v1.6.0.

@Ant-ON
Copy link
Collaborator

Ant-ON commented Nov 6, 2020

@gcohara Could you try develop branch? I tested it on stm32f07 and it's work.

@gcohara
Copy link
Author

gcohara commented Nov 6, 2020

Just tried it on the develop branch and I can confirm it's working!
Sorry, I really ought to have done that anyway.

@gcohara gcohara closed this as completed Nov 6, 2020
@Nightwalker-87 Nightwalker-87 reopened this Nov 6, 2020
@Nightwalker-87
Copy link
Member

Please don't close open tickets as this is working against regular maintenance tasks and tracking. Resolved tickets are closed automatically by the issue tracking system.

@Nightwalker-87
Copy link
Member

@Ant-ON: Is this related to PR 1027 as well?

@Ant-ON
Copy link
Collaborator

Ant-ON commented Mar 15, 2021

@Nightwalker-87 Yes, it fixed by #1027

@stlink-org stlink-org locked as resolved and limited conversation to collaborators Mar 15, 2021
@Nightwalker-87 Nightwalker-87 moved this to Done in Release v1.7.0 Apr 7, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.