STM32 with ST-Link V3 debugger does not start properly

[jbur83]

I tried to debug a Project on STM32 with ST-Link debugger. The project debugs fine with IAR EW 8.40.2

My Launch config is

{
    "configurations": [
        
        {
            "type": "cspy",
            "request": "launch",
            "name": "SU613_bootloader.Debug",
            "target": "arm",
            "program": "${workspaceFolder}\\Debug\\Exe\\SU613_bootloader.out",
            "driver": "stlink2",
            "stopOnEntry": true,
            "workbenchPath": "${command:iar-config.toolchain}",
            "projectPath": "${workspaceFolder}\\SU613_bootloader.ewp",
            "projectConfiguration": "Debug",
            "driverOptions": [
                "--endian=little",
                "--cpu=Cortex-M4",
                "--fpu=None",
                "-p",
                "C:\\MyPrograms\\IAR Systems\\Embedded Workbench 8.3\\arm\\CONFIG\\debugger\\ST\\STM32F405VG.ddf",
                "--semihosting",
                "--device=STM32F405VG",
                "--drv_interface=SWD",
                "--stlink_reset_strategy=0,0",
                "--drv_swo_clock_setup=168000000,1,2000000",
                "--drv_catch_exceptions=0x000",
                "--drv_debug_ap=0",
                "--stlink_probe=stlinkv3"
            ],
            "download": {
                "flashLoader": "C:\\MyPrograms\\IAR Systems\\Embedded Workbench 8.3\\arm\\config\\flashloader\\ST\\FlashSTM32F4xxx.board",
                "deviceMacros": [
                    "C:\\MyPrograms\\IAR Systems\\Embedded Workbench 8.3\\arm\\config\\debugger\\ST\\STM32F4xx.dmac"
                ]
            }
        }
    ]
}

The output on the debugging-console is as follows:

Initializing flash loader manager using C:\MyPrograms\IAR Systems\Embedded Workbench 8.3\arm\config\flashloader\ST\FlashSTM32F4xxx.board
Loading flash module: C:\MyWorkspace\MyProj_bootloader\Debug\Exe\MyProj_bootloader.out
Loaded macro file: c:\MyPrograms\IAR Systems\Embedded Workbench 8.3\arm\config\flashloader\ST\FlashSTM32F4xxx.mac
Connected to ST-Link/V3 [SWD mode 1000 kHz] [Access port: 0] Firmware V3.J03.S0 (Probe no: 34313939)
Hardware reset with strategy 0 was performed
Initial reset was performed
992 bytes downloaded (20.61 Kbytes/sec)
Loaded debugee: c:\MyPrograms\IAR Systems\Embedded Workbench 8.3\arm\config\flashloader\ST\FlashSTM32F4xxxRAM128K.out
Target reset
Unloaded macro file: c:\MyPrograms\IAR Systems\Embedded Workbench 8.3\arm\config\flashloader\ST\FlashSTM32F4xxx.mac
Downloaded C:\MyWorkspace\MyProj_bootloader\Debug\Exe\MyProj_bootloader.out to flash memory.
59914 bytes downloaded into FLASH (7.83 Kbytes/sec)
Flash loading completed successfully.
Hardware reset with strategy 0 was performed
Loaded debugee: C:\MyWorkspace\MyProj_bootloader\Debug\Exe\MyProj_bootloader.out
Hardware reset with strategy 0 was performed
Target reset
Shutting down C-SPY...

So principially, communication with debugger and target seems to be fine. Debugger-LEDs are blinking red/green as expected. But then, it quickly aborts without starting at the main.c entry point

[jbur83]

by the way. VS-Code does not recognize stlink2 as a proper setting for driver

[VzdornovNA88]

Do I understand correctly that upgrading to 8.5 version won't fix this issue?

[hans-f-iar]

I will try to reproduce this today. I did a test with ST-Link on a STM32H753 board yesterday and that worked with the latest debug extension. I'm not sure exactly what version of ST-Link I was using but think that board has v2. The driver is set to stlink2 if I use EWARM 8.50.5 and that is recognized by the extension.

[jbur83]

Do I understand correctly that upgrading to 8.5 version won't fix this issue?

I actually could not try. I'm bound to IAR EW 8.40.2 / Embedded Workbench 8.3 due to my company/project

[jbur83]

I will try to reproduce this today. I did a test with ST-Link on a STM32H753 board yesterday and that worked with the latest debug extension. I'm not sure exactly what version of ST-Link I was using but think that board has v2. The driver is set to stlink2 if I use EWARM 8.50.5 and that is recognized by the extension.

My CPU to debug is STM32F405.
My STM-Debugger is STLINK-V3MINI (https://www.st.com/en/development-tools/stlink-v3mini.html)

In the EW, I select V3

After debugging with EW once, the config has been discovered as stlink2

[hans-f-iar]

I tried to reproduce this but I got the unsupported transport error from #10 instead.

I don't have the exact board as you have but have tried with a STM32F14 with ST-Link v2 and a STM32H753 with ST-Link v3.

My fear is that even if I'm able to reproduce your issue and help you get further, then you will get the unsupported transport error instead and that will stop you from using this extension. I will talk next week with a few that returns from vacation and see if I can get some more ideas about the problem you have though.

[jbur83]

Thank you very much. I'll stay tuned and let me know if you need further information or logs...

[VzdornovNA88]

I may be wrong, but the extension has an enumeration that does not contain a special constant for version 2 of the stlink driver, if it works for IAR workbench version > 8.4, then I can assume that another IAR makes other entries in the files .xcl as an example to fix this problem. From now on we should update our version of IAR, however I still don't understand if we only have this problem why this extension supports such a later version of IAR because we can add new constants for stlink1,2,3.... for IAR of earlier versions , but if problem #10 is still attached, then of course we have to update IAR.

[HampusAdolfsson]

To clarify, after you get the "Target reset" message, does the debug session end immediately, or does it stall/hang?
If the latter, this could be the same bug as described in #5. If you wait a couple of minutes at this point, you should see something happen (most likely you will get the "unsupported transport" error).

Regarding the warning about unrecognized driver names: older Embedded Workbench versions use slightly different driver file names, and the extension doesn't handle this. It will still load the driver, but it means the launch.json file will have the driver file name ("stlink2"/"xds2") instead of the prettified name ("ST-LINK"/"TI XDS"). I will fix this in the next release.

[VzdornovNA88]

Hi, thanks for the quick response, in my opinion we don't really need this fix because after that we will have a general "unsupported transport" problem, so unfortunately we will have to update our EW version anyway.

As for the details of the debugging process, I get an "unsupported transport" in about a few minutes.

Also , I haven't seen #5 yet, but I'm gonna...