STM32L496xx: MCU restarts after running st-util, loading image

[mykmelez]

When I run st-util 1.6.1, the board restarts rather than waiting for me to start arm-none-eabi-gdb, load the image, and continue. And it often (although not always) also restarts right after I load the image, before I enter continue. In st-util 1.6.0, the board wouldn't restart until after I started arm-none-eabi-gdb, loaded the image, and entered continue.

• Programmer/board type: ST-LINK/V2
• Programmer firmware version: V2J29S7
• Operating system and version: macOS Catalina 10.15.5
• Stlink tools version: v1.6.1 (installed via Homebrew)
• Stlink commandline tool name: st-util
• Target chip (and board if applicable): STM32L496xx

Commandline-Output:

Running st-util 1.6.1 shows this output:

> st-util
st-util
2020-06-08T14:56:16 INFO common.c: L496x/L4A6x: 256 KiB SRAM, 1024 KiB flash in at least 2 KiB pages.
2020-06-08T14:56:16 INFO gdb-server.c: Listening at *:4242...

And then the board restarts. Starting arm-none-eabi-gdb and then loading the image often (but not always) also results in the board restarting after the image has been loaded, but before I enter continue.

Expected/description:

st-util 1.6.0 showed this instead:

st-util 1.6.0
2020-06-08T14:57:16 INFO common.c: Loading device parameters....
2020-06-08T14:57:16 INFO common.c: Device connected is: L496x/L4A6x device, id 0x20006461
2020-06-08T14:57:16 INFO common.c: SRAM size: 0x40000 bytes (256 KiB), Flash: 0x100000 bytes (1024 KiB) in pages of 2048 bytes
2020-06-08T14:57:16 INFO gdb-server.c: Chip ID is 00000461, Core ID is  xxxxxxxx.
2020-06-08T14:57:16 INFO gdb-server.c: Listening at *:4242...

And the board didn't restart until I started arm-none-eabi-gdb, loaded the image, and entered continue.

[Nightwalker-87]

Honestly I don't really understand this issue report.
Maybe the correct workflow should be updated in our documentation, but for that we need someone who is clearly aware of how things should proceed step by step during a gdb debugging routine.

[Ant-ON]

@Nightwalker-87
@mykmelez st-util has the --no-reset argument (#1114 add synonim --hot-plug). This argument disables the reset on connect

[Nightwalker-87]

There may be no response from the author any more. I still can't see the error yet.

[mykmelez]

There may be no response from the author any more. I still can't see the error yet.

I'm still responsive, just not able to respond immediately. I'll dig in further to see how I can describe the issue better and/or isolate it to a specific change between 1.6.0 and 1.6.1.

[mykmelez]

I bisected between v1.6.0 and v1.6.1 and identified the regressing commit:

09ea99aea51f741ce9c8c0e2ad755d40b3d86021 is the first bad commit
commit 09ea99aea51f741ce9c8c0e2ad755d40b3d86021
Author: Miklós Márton <martonmiklosqdev@gmail.com>
Date:   Mon Feb 24 21:34:36 2020 +0100

    Add support for STLink V3
    Flash programming is broken

 include/stlink.h             |  68 +++++++-
 include/stlink/commands.h    |  48 +++---
 include/stlink/tools/flash.h |   2 +-
 include/stlink/usb.h         |  14 +-
 src/common.c                 | 100 +++++++-----
 src/flash_loader.c           |   4 +-
 src/gdbserver/gdb-server.c   |   2 +-
 src/logging.c                |   2 +-
 src/sg.c                     |  20 +--
 src/tools/flash.c            |  10 +-
 src/usb.c                    | 368 ++++++++++++++++++++++++++++++++++---------
 11 files changed, 479 insertions(+), 159 deletions(-)

Unfortunately, that's rather a large commit, and I'm not very familiar with this codebase (nor STM32 programming more generally), so it isn't immediately obvious to me where the problem might be nor how to debug it.

I can run my build of st-util in a debugger, however, and I'm happy to do so, if you have some ideas about where the issue might be that you'd like me to investigate.

FWIW, I use a .gdbinit file that looks like this:

set remotetimeout 20
target ext :4242
file name-of-file.elf
load
mem 0x20040000 0x20050000 rw nocache

(I know that last line is redundant in st-link 1.6.1, but my team is still pinned to 1.6.0 because of this issue.)

Here's what gdb output looks like when I start gdb with a build of st-util from before the regressing commit:

GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 8.0.50.20171128-git
…
0x08000718 in ?? ()
Loading section …
…
Start address 0x8009544, load size 815732
Transfer rate: 19 KB/sec, 15106 bytes/write.
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x08002918 in ?? ()
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: name-of-file.elf 

Then my program starts running on the target.

When I start gdb with a build of st-util on/after the regressing commit, however, I see this:

GNU gdb (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 8.0.50.20171128-git
…
0xfffffffe in ?? ()
Loading section …
…
Start address 0x8009544, load size 815732
Transfer rate: 19 KB/sec, 15106 bytes/write.
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0xfffffff0 in ?? ()
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: name-of-file.elf 

Program received signal SIGTRAP, Trace/breakpoint trap.
0xfffffff8 in ?? ()
(gdb) 

In other words: the program fails to start, even on the second try. And subsequent tries continue to fail.

Note that the program sometimes fails to start on the first try even before the regressing commit. But when that happens, it always starts the second time.

After the regressing commit, however, sometimes it successfully starts on the first try; but when it doesn't, then it never succeeds.

[Nightwalker-87]

@mykmelez Thanks for the update and the details.
The mentioned commit appears to have introduced some other issues as well in the past.
I'll try to find a more specific hint.

[Nightwalker-87]

Here is the graphical view of the mentioned commit: 09ea99a

I may assume the relevant change is in src/gdbserver/gdb-server.c as it is related to the use of st-util.
Can you try if reverting that change there does have any effect?