search

stlink-org / stlink

Open source STM32 MCU programming toolset
BSD 3-Clause "New" or "Revised" License
4.34k stars 1.23k forks source link

[feature] STLINK-V3 support #1025

Closed lcharpenwi6labs closed 3 years ago

lcharpenwi6labs commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@Nightwalker-87 wrote:

do some final verification

Please correct me when I'm wrong

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

Nightwalker-87 commented 3 years ago

@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 commented 3 years ago

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

stappersg commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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:

I have STM32L051R8, where the situation is worse:

I also had an STM32F030CC:

Nightwalker-87 commented 3 years ago

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