[STM32L4R5ZI]: Odd reset on Nucleo-L4R5ZI

[rpls]

• I made serious effort to avoid creating duplicate or nearly similar issue

In order to allow developers to isolate and target your respective issue, please take some time to select the check boxes below and fill out each of the following items appropriate to your specific problem.

• Programmer/board type: STLINKV2-1
• Operating system an version: Linux
• stlink tools version and/or git commit hash: v1.7.0
• stlink commandline tool name: st-flash & st-util
• Target chip (and board, if applicable): Nucleo-L4R5ZI / STM32L4RZI

Further we kindly ask you to describe the detected problem as detailed as possible and to add debug output if available, by using the following template:

Commandline output:

Command line output does not appear to be relevant.

2021-06-13T23:33:10 INFO common.c: L4Rx: 640 KiB SRAM, 2048 KiB flash in at least 4 KiB pages.
2021-06-13T23:33:10 INFO gdb-server.c: Found 6 hw breakpoint registers
2021-06-13T23:33:10 INFO gdb-server.c: GDB connected.
2021-06-13T23:33:10 INFO common.c: L4Rx: 640 KiB SRAM, 2048 KiB flash in at least 4 KiB pages.
2021-06-13T23:33:10 INFO gdb-server.c: flash_erase: block 08000000 -> 7000
2021-06-13T23:33:10 INFO gdb-server.c: flash_erase: page 08000000
EraseFlash - Page:0x0 Size:0x1000 2021-06-13T23:33:10 INFO gdb-server.c: flash_erase: page 08001000
EraseFlash - Page:0x1 Size:0x1000 2021-06-13T23:33:10 INFO gdb-server.c: flash_erase: page 08002000
EraseFlash - Page:0x2 Size:0x1000 2021-06-13T23:33:10 INFO gdb-server.c: flash_erase: page 08003000
EraseFlash - Page:0x3 Size:0x1000 2021-06-13T23:33:10 INFO gdb-server.c: flash_erase: page 08004000
EraseFlash - Page:0x4 Size:0x1000 2021-06-13T23:33:10 INFO gdb-server.c: flash_erase: page 08005000
EraseFlash - Page:0x5 Size:0x1000 2021-06-13T23:33:10 INFO gdb-server.c: flash_erase: page 08006000
EraseFlash - Page:0x6 Size:0x1000 2021-06-13T23:33:10 INFO common.c: Starting Flash write for F2/F4/F7/L4
2021-06-13T23:33:10 INFO flash_loader.c: Successfully loaded flash loader in sram
2021-06-13T23:33:10 INFO flash_loader.c: Clear DFSR
2021-06-13T23:33:10 INFO gdb-server.c: flash_do: block 08000000 -> 7000
2021-06-13T23:33:10 INFO gdb-server.c: flash_do: page 08000000
2021-06-13T23:33:10 INFO gdb-server.c: flash_do: page 08001000
2021-06-13T23:33:10 INFO gdb-server.c: flash_do: page 08002000
2021-06-13T23:33:10 INFO gdb-server.c: flash_do: page 08003000
2021-06-13T23:33:10 INFO gdb-server.c: flash_do: page 08004000
2021-06-13T23:33:11 INFO gdb-server.c: flash_do: page 08005000
2021-06-13T23:33:11 INFO gdb-server.c: flash_do: page 08006000

Expected/description:

The board and/or chip appears to exhibit a different reset behavior. When using either st-flash when simply flashing binaries, or when using a gdb-server with st-util and performing a GDB load, the board/chip will end up in a weird hanging state after flashing. Flashing itself is successful, but the PC ends up at something like 0x1fff5240. Either a manual reset with a reset button, or flashing again will put the chip into the correct state again (i.e., PC at 0x8000000). Using --connect-under-reset or --reset does not change this behavior. I investigated the problem a bit, and noticed that OpenOCD has the same problem, but mentions that it detected an "external reset". With OpenOCD I can change the configuration as to how the chip is reset. Here I can add a setting like reset_config trst_only (default, i think, is srst_only?), which will completely fix this problem.

Note: I don't think it's related to #1138.

[Ant-ON]

@rpls This behavior may be caused by calling a soft reset. You can try building the develop branch with the lines commented out:

stlink/src/common.c

Lines 1779 to 1781 in e571908

	if (sl->backend->reset(sl)) {
	return (-1);
	}

In this case, run st-flush with the --reset argument is likely to succeed.

[Nightwalker-87]

Fixed in #1154.