-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
STM32H750: GDB breakpoints do not halt execution #1059
Comments
@Ant-ON I replaced the two |
Hey, I was wrong! The patch works, but only sometimes. Still trying to figure out under which circumstances... |
Hi, I am responsible for reviving the STM32H7 patch. What I have found is that the chip can only be reliably detected when connected under reset. The problem appears to be that stlink_chip_id() in common.c reads an actual value from 0xE0042000, so it never falls through to the next statement, which attempts to read from 0x5C001000 (as is desired with the STM32H7). Maybe someone can suggest a better approach to detecting the STM32H7? |
General suggestion: Review & refactor the |
I'm pretty sure the chip is reliably detected correctly. I don't think I've seen issues there. Output of
Regarding the breakpoints: There might be a certain probability that breakpoints halt execution. Breakpoints in initialization code almost never halt, while those in loops do. On a side note: I added a specialized GDB memory map to |
@timothytylee You may use core_id to identify STM32H7 series. For example something like this:
|
@cmdrf Also for H7 you need to enable cache support. This series of MCU has it. Change |
@Ant-ON Now
But breakpoints are still flaky. |
@cmdrf It's from reference of Cortex-M7: https://developer.arm.com/documentation/dui0646/a/cortex-m7-peripherals/processor-features/cache-level-id-register I read Cortex-M7 and ARMv7-M reference manual and small rewrote code of gdb-server: https://github.com/Ant-ON/stlink/tree/try_h7_debug |
@Ant-ON I tried your core_id patch and it did not improve the detection problem on my PC. I still need to connect under reset to reliably detect the H7, otherwise it succeeds only 1 out of 8 times. A question about the JTAG ID code: I found two listed in RM0433: page 3065 says IDCODE is 0x6ba00477, but page 3066 says DP_DPIDR register contains 0x6ba02477 (which is what my board returns). Is this a typo from ST, or is something else happening here? |
@timothytylee after the patch, which register read incorrectly? 0x6ba00477 it's ID code read from JTAG-DP (via JTAG) |
@Ant-ON , I was testing on the NUCLEO-H7432ZI2. The value in sl->core_id was 0x6ba02477. |
@timothytylee everything is correct. But why then the MCU is not determined the first time? Incorrect read from chip_id register (0x5c001000)? |
@cmdrf Can you try this rewrited code? |
@Ant-ON I'm on it in this very moment. But no luck so far. It seems it doesn't even trigger breakpoints in heavy-duty loops. I noticed that cache support isn't enabled in that branch (at least I don't see LoUIS and friends anymore). Maybe that would help. I'll try and add it back in. |
@cmdrf I changed the code a bit. Now the choice of the style of breakpoints and the enabling of cache support is automatic. I think this solution is the most optimal: https://github.com/Ant-ON/stlink/tree/try_h7_debug ps Can you try to build a project without optimization (-O0)? |
Hey, I found something interesting: If I start the program through the debugger, then hit the reset button on the dev board, from then on it stops at every breakpoint I throw at it! However, when I want to continue execution, it stops at the same breakpoint again without actually executing anything. Maybe this is important: In my projects I exclusively use the 4-pin SWD connection (SWDIO, SWCLK, 3.3V and GND) and don't connect the reset pin. @Ant-ON I'm going to test your branch now. |
@Ant-ON I tested your branch now, and as far as I can tell, it behaves the same as I investigated this further, and it turns out it stops at the loop breakpoints every time (meaning my earlier theory about there being a chance of hitting was wrong). However, continuing execution stops immediately again without executing anything. So a new theory would be (incorporation observations with the reset button): There is a certain time after program start where breakpoints don't work, and continuing from breakpoints doesn't work. But breakpoints work in general.
|
So, I did this: int counter = 0;
while (1)
{
HAL_Delay(10); // Milliseconds
counter++;
HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_15);
} right after HAL and GPIO initialization and put a breakpoint in the (The time is shorter and more inconsistent through my IDE. I guess the IDE introduces its own delays in between gdb commands) |
@Ant-ON, regarding the incorrect detection of STM32H7: yes, the problem is that 0x5c001000 is returning the wrong value (0x05fa0004). Coincidentally, this is the value written to AIRCR (address 0xe000ed0c), just prior to the read. |
@timothytylee This is very similar to reset problems... I tried rewriting the reset function. I'm checked the work it on the existing hardware with F07/F1/F3/G4 chips. https://github.com/Ant-ON/stlink/commits/try_h7_debug @cmdrf Perhaps correcting the reset will somehow affect the breakpoints. If possible, then I think it's worth checking. |
@Ant-ON Your try_h7_debug branch fixed the NUCLEO-H7432ZI2 detection problem! |
@cmdrf I've tweaked gdb a bit. Could you try https://github.com/Ant-ON/stlink/commits/try_h7_debug ? |
Related to #1063. |
Hey that works! Only a slight build error on 32 Bit ARM because of
The "NRST is not connected" bit is true btw. Buut...I also got it working with my branch https://github.com/cmdrf/stlink/tree/stm32h7-breakpoint-almostfix now, where I accumulated all the patches concerning cache support etc. found in this thread. The weird breakpoint behavior seems to stem from the fact that I use TIM1 as the HAL time base. The timer interrupt seems to fire right after continuation and it ends up hitting the same breakpoint again when it returns from the interrupt handler. Why it takes two seconds after program start for the first breakpoint to trigger is still a mystery though. Anyway, when I switch this back to the SysTick interrupt, the breakpoints work as expected. Maybe this is a known issue when debugging and I'm just stupid 😕 ? Are timers supposed to run when the program is halted? |
@cmdrf Thanks for the mistake with the size_t! I will fix it. try_h7_debug is a bit smarter. It determines a reset occurred when the NRST was switched. Only after that it uses a software reset. The TIM1 timer is probably incorrectly configured. It may have much higher frequency than expected. Eclipse IDE sets breakpoints after starting the program. Something like this happens:
|
I made serious effort to avoid creating duplicate or nearly similar issue
Programmer/board type: Stlink/v2-clone
Operating system and version:
st-util
: Armbian Linux, a Debian 10 derivative.gdb
: macOS 10.15.6Stlink tools version and/or git commit hash: 1e20921
Stlink command line tool name:
st-util
Target chip: STM32H750VBT6
Command line output:
Expected/description:
The execution should stop at the specified breakpoint location, which is inside
main()
. I also tried various other locations, but it never stops. The same setup works with various other STM32 devices and otherst-link
versions.This is a followup to #1011 .
Thanks for your effort!
The text was updated successfully, but these errors were encountered: