stlink
stlink copied to clipboard
stlink-org
[reset] st-util can not debug stm32l43x reliably
I am using stm32l433_nucleo board. I need to debug this board in Linux(ubuntu16.04) frequently.
I have troubles with debugging using st-util:
-
st-util can not halt mcu reliably frequently, when I start arm-none-eabi-gdb, I find the CPU is not halted as expected, shows: 0x1fff3f36 in ?? () then I will not be able to debug properly. Got to restart st-util several times to get it working again.
-
I can not load program as soon as gdb connect to st-util server when I start gdb(with command: arm-none-eabi-gdb path/to/my/elf -ex "target extended-remote :4242"), I need to run "continue" command first, before I can "load" my program. Otherwise, debug won't work: I won't be able to stop(Ctrl-C) or set breakpoints properly.
tools version info: arm-none-eabi-gdb: 7.10.1.20160923-cvs st-util: 1.4.0-13-g1969148
What are the causes of these problems?
This has been a long standing problem for users of the texane/stlink tooling. Nobody has yet come up with a solution and bug reports related to this are piling up. OpenOCD handles this a little different as you can chose connect-under-reset which is not currently possible as far as I know.
I had the same problem. The Reference Manual says "A Flash empty check mechanism is implemented to force the boot from system Flash", which is at 0x1FFF0000. Although having the board programmed correctly ( i did check with the ST-Link Utility), it did not work. A power cycle fixed the problem, whereas connect-under-reset did not work.
@Ant-ON I think the load-stop-continue problem is fixed by now.
However I am not so sure about the core halt, because I have seen, as I believe, somehow similar output to 0x1fff3f36 in ?? () recently (see #1038).
So looking at this, I can't tell whether the core halt works for all STM32 cores yet.
@Nightwalker-87 The problem is old enough version of tool. I did not specifically fixing this problem. Possible indirect fixes when rework reset or flash loaders. #1038 is not related with this issue.
Yes it's an old version of the toolset, I know. I'll have a look in the project history for references.
However, output like 0x1fff3f36 in ?? () or similar, as also seen in the cited issue, does not look correct to me.
@Ant-ON I was not pointing at #1038 itself, but the testing i did within this issue.
@Nightwalker-87 This is a different problem. The #1038 had regression problems when implementing st-link/v3. I have not seen the described problem on my boards. But I have only F series boards.
Since V1.8.0 has been installed, this seems pretty much rock solid or me. Thanks to whoever put the effort in- it's a different world now! Win10
@radsdau Can you give some more information on your hardware and what you tried out exactly? That would be great, thx. We're looking forward to close this issue if one can verify this issue is resolved. Also others may then be able to reproduce.
@Nightwalker-87 I am debugging a STM32L4Q5VGT6 with STLink-V3Mini. In V1.7 starting a debug session would fail about 50% of the time, as described in this bug report; it had halted in some unknown location (0x1FFFxxxx). I'd hit 'debug' again, it would go through the entire process, then work the next time. It was also flakey and dropped out (some exception) often. I'm running this on Win10, and our app has 3 FreeRTOS tasks running. As of V1.8.0 I haven't seen this behaviour at all- it's started a debug session every time. I hope that's the info you needed. Cheers
Ah, that does ring a bell indeed. I remember a very similar issue regarding the behaviour you just described. It was fixed somewhen recently. This could indeed be a duplicate of it. Let me check, it won't be difficult to find out...
Since V1.8.0 has been installed, this seems pretty much rock solid or me. Thanks to whoever put the effort in- it's a different world now! Win10
Did you compile binaries manually? Is there any chance to share them?
@KlemenDEV They can be created following the instructions in our compiling instructions in /doc. It is misleading to talk about v1.8.0 however as there is no such version yet. We are currently working on v1.7.1.
@radsdau Could you test older versions as well in order to get an idea of where this was fixed actually? This would allow for an update of our CHANGELOG.md.
This issue is now closed due to inactivity.
Please also note that any version prior to v1.7.0 is unsupported according to our #Security Policy.
Should the problem persist, please retry with the latest version in the develop branch.
If this is the case, one should then open a new ticket.