[reset] st-util can not debug stm32l43x reliably

[Cheng-SG]

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:

1. 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.

2. 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?

[xor-gate]

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.

[b10X1EDE0]

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]

@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.

[radsdau]

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

[Nightwalker-87]

@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.

[radsdau]

@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

[Nightwalker-87]

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...

[KlemenDEV]

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?

[Nightwalker-87]

@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.

[Nightwalker-87]

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.