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

STM32F103CB: All the Register values are wrongly shown when running info registers #1065

Closed
hannanmumtaz opened this issue Nov 7, 2020 · 7 comments · Fixed by #1027
Closed

Comments

@hannanmumtaz
Copy link

  • Programmer/board type: Stlink v2
  • Operating system and version: Windows
  • Stlink tools version and/or git commit hash: v1.6.1
  • Stlink commandline tool name: st-util
  • Target chip (and board if applicable): STM32F103CB

When command info registers is run on gdb i get the wrong output.

I was trying to set register r7 to 0xDEADBEEF using assembly

.syntax unified
.cpu cortex-m3
.fpu softvfp
.thumb

.global vtable
.global reset_handler

.type vtable, %object
vtable:
    .word _estack
    .word reset_handler
.size vtable, .-vtable


.type reset_handler, %function
reset_handler:

    LDR  r0, =_estack
    MOV  sp, r0
    LDR  r7, =0xDEADBEEF
.size reset_handler, .-reset_handler

Commandline-Output:

image

OUTPUT/ERROR of the commandline tool(s)

all register values are shown as r# + 1 so instead of r7 being 0xDEADBEEF r8 is shown with that value also even the stack pointer value is shown infront of lr register.

Expected/description:

r7 should be shown with correct value in registers.
below is the output when using openocd

all registers are correctly displayed when using openocd server.

image

Thanks in advance.

@Ant-ON
Copy link
Collaborator

Ant-ON commented Nov 9, 2020

@hannanmumtaz Can you try the develop branch? This should be fixed by #1027

@hannanmumtaz
Copy link
Author

Hi, i tried the develop branch, i see now the registers values are correct, so the original issue is resovled.

But, i noticed some other issues in develop branch maybe i have to create separate ticket for these.

  1. calling load in gdb automatically starts execution , previously that was not that case.
  2. if a program is already running on the mcu, attaching to it via target extended-remote doesn't stop execution and program keeps running, not the case in v1.6.1 or openocd.
  3. calling starti restarts the program but program keeps running in background and prints a random break location which is incorrect as program is never halted after restart.
  4. calling step in gdb hangs the gdb and has to be stopped and restarted.

@Ant-ON
Copy link
Collaborator

Ant-ON commented Nov 10, 2020

@hannanmumtaz The first problem I solved in this branch: https://github.com/Ant-ON/stlink/tree/try_h7_debug I will try to look at and solve other problems. It's better to create a separate issue.

@Ant-ON
Copy link
Collaborator

Ant-ON commented Dec 29, 2020

@Nightwalker-87 The main problem is solved. Issues were not created for other problems. I think the current issue can be closed.

@Nightwalker-87
Copy link
Member

@hannanmumtaz: If still relevant: Please check currently open tickets for the other topics and open new issues, if necessary.

@Ant-ON: Can you confirm that the mentioned PR fixes this issue?

@Ant-ON
Copy link
Collaborator

Ant-ON commented Mar 12, 2021

@Nightwalker-87 Yes, the problem described in the first post has been fixed

@Nightwalker-87
Copy link
Member

Fixed in PR #1027.

@stlink-org stlink-org locked as resolved and limited conversation to collaborators Mar 12, 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.
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants