STM32 with ST-Link V3 debugger does not start properly about iar-vsc-debug

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