[feature] STLINK-V3 support

[lcharpenwi6labs]

• Programmer/board type:Stlink V3
• Operating system and version: Linux
• Stlink tools version and/or git commit hash: v1.6.1-93-g5c03678
• Stlink commandline tool name: st-util
• Target chip (and board if applicable): STM32G474RE

Hello
I would like to start debugging with STM32G4 but it doesn't seem to be fully supported at this time.
Here is the command I launch

xterm -e st-util -v99 -p4343&
ddd --eval-command="target extended 127.0.0.1:4343" --debugger arm-none-eabi-gdb hello-world.elf

I seems the commands launched from GDB have few impact on the target.
When I run the kill command, it is correctly caught by gdb_server.c but the program continues running.

Here is what I have in the gdb console.
2020-09-08T17:07:15 DEBUG gdb-server.c: recv: vKill;a410
2020-09-08T17:07:15 DEBUG gdb-server.c: send: OK
2020-09-08T17:07:15 DEBUG gdb-server.c: recv: ?
2020-09-08T17:07:15 DEBUG gdb-server.c: send: OK

Same thing when I set a breakpoint...
2020-09-08T17:08:42 DEBUG gdb-server.c: recv: Hg0
2020-09-08T17:08:42 DEBUG gdb-server.c: send:

Sometimes the system says it is stopped at a mysterious address (0x01000000) but the program continues running.

Something should have changed between stlinkv2 and v3 but it doesn't seem to be possible to find any specification...
Is there any specificities for the G4 board?
If anyone has any suggestion, I can test it.

Thanks for your support

[stappersg]

On Tue, Sep 08, 2020 at 08:15:01AM -0700, lcharpenwi6labs wrote: Something should have changed between stlinkv2 and v3 but it doesn't seem to be possible to find any specification... Is there any specificities for the G4 board? If anyone has any suggestion, I can test it.

Somehow I do read

"I have this whole chain of links, each link is new to me and the chain doesn't work as expected"

Advice: Get a working chain and swap single links with yet unknown link.

Thanks for your support

Summary: The reported issue has been seen

[Nightwalker-87]

Can we do some final verification with different STLINKv3 programmers to verify that common functionality is present?
If this is the case please post useful results here and let me know about it.
This is one of the main features for the next release and also would help to close a few related issues.

[stappersg]

@Nightwalker-87 wrote:

do some final verification

Please correct me when I'm wrong

• git checkout develop
• git pull
• Report the commit hash, the first 7 characters will do
• Build
• Report the firmware version (it is in some file that is on the USB device)
• Report information about the computer relevant to this test. ( Operating System info, libusb version, .... )
• ./st-info --probe
• ./st-flash --read ..... ..... ....

P.S. @lcharpenwi6labs
If you made other progress in the month since opening this issue, please report it.

[Nightwalker-87]

@stappersg: Yes and maybe there are some additional tasks during common use, like writing option bytes, OCD, etc.
Who ever is willing to contribute: Feel free to make up your mind what seems reasonable - the more the better.

I personally can't contribute very much on this topic, as I don't have any access to STLINKv3 hardware (without additional spending) and also no use case for it at the moment. However I'd be pleased to integrate and review your input to finally get this feature on the way.

[Ant-ON]

I think it regression is fixed by #1027.
@lcharpenwi6labs May you try latest develop branch?

[stappersg]

My reason of being silent is a mix of priority shift and having found https://probe.rs/

unlikely that I soon will have time for this issue,.

[Nightwalker-87]

@lcharpenwi6labs If still relevant, you may give it another try by following the advice from @stappersg.
However, reading this indicates that the observed behaviour is not specifically related to the STLINK/V3.
Further coverage on STLINK/V3 support and testing can be found in #820.
This issue also seems related to #1022.

[martonmiklos]

Well I pulled in some gear to do a test drive, and the results are promising, but it looks that there is still an area of improvement:
STM32F031K6:

• probe works,
• read works,
• write fails first
• second attempt the write succeds
  https://gist.github.com/martonmiklos/91bc396f1130a5da554970cd76f34116

I have STM32L051R8, where the situation is worse:

• probe works
• read looks okay
• write stuck - I had to kill with killall -9 because Ctrl+C did not helped
  https://gist.github.com/martonmiklos/20bdd7aee631f62ac689c5268854fbb8

I also had an STM32F030CC:

• probe works, however it detected as F09X
• Read works
• Write fails once
• Second time it succeds, however either the read contents were bad or the write failed, it needs to be investigated, but atm I lack of time.
  https://gist.github.com/martonmiklos/d688b2a0156bbe3154e44e9d9053c063

[Nightwalker-87]

@martonmiklos: Thx for the feedback. The first write fail is a general issue which is covered in #356.
Please point out the STM32L051R8 issue in the main discussion in #820.