Unsupported transport error

[andrewtkh1]

Does anyone have any clue on how do I go about resolving this issue? I was able to build using the IAR Build extension and generated the launch config from there but encountered this error when trying to debug it.

As Couldn't find much support online and I do not have much experience in this.

[andrewtkh1]

Was able to bypass this issue by updating my IAR EW to 9.30.1

[VzdornovNA88]

Hi everyone I have the similar problem.

I am trying to run debug but the VS CODE doesn't run the session and shows the same message.

I've enabled ""trace": true" flag in the launch setting and have gotten "Unable to recognize driver: stlink2" while VS CODE editor underlines the property ""driver": "stlink2"" and sends to me "Value is not accepted. Valid values: "Simulator", "64-bit Simulator", "I-jet", "J-Link/J-Trace", "GDB Server", "CADI", "TI Stellaris", "PE micro", "ST-LINK", "TI XDS", "TI MSP-FET", "Renesas E1", "Renesas E2", "Renesas E20".". Is it possible to add stlink2 variant to this set of driver?

[NicolasHDD]

Having exactly the same issue.

IAR build: Embedded Workbench 8.3
Debugger: TMS320-XDS100V3 Olimex board (compatible with IAR)

Everything works fine with IAR but I also have that transport error with the extension.

I also tried to change the driver (which is automatically set to xds2 for some reason) to "TI XDS" as indicated but it's not recognized, so same issue as @VzdornovNA88

In the debug console log I noticed a difference between IAR and the extension:

On IAR:
IAR Embedded Workbench 8.40.1 (C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.3\arm\bin\armproc.dll)

On the extension:
Driver loaded: C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.3\arm\bin\armXDS2.dll

It looks like it's not even the same driver being loaded...

@andrewtkh1 Since it's working for you, can you tell me which driver you're using ?

For those interested, here's the full log of the extension:

Using C-SPY version: 8.3.2.5988
Driver loaded: C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.3\arm\bin\armXDS2.dll
Loaded macro file: C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.3\arm\config\debugger\TexasInstruments\CC26x0.dmac
Initializing flash loader manager using C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.3\arm\config\flashloader\TexasInstruments\FlashCC26x0F128RAM20.board
Loading flash module: C:\Users\nharel\Dev\XXXX\Env\Debug\Exe\RF6XXX.out
Loaded macro file: C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.3\arm\config\flashloader\TexasInstruments\FlashCC26xx.mac
No SWO port found, SWO disabled
Connecting to TI XDS100v3 ( Probe no: FTG0Y5I ) COM[--/--]
TI XDS ARM, device revision: 0x00000001, big endian: false, cache: false, board revision: 0x00000000, driver revision: 0x0B020200
Initial reset was performed
1056 bytes downloaded (8.25 Kbytes/sec)
Loaded debugee: C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.3\arm\config\flashloader\TexasInstruments\FlashCC26x0RAM20.out
Target reset
Unloaded macro file: C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.3\arm\config\flashloader\TexasInstruments\FlashCC26xx.mac
Downloaded C:\Users\nharel\Dev\XXXX\Env\Debug\Exe\RF6XXX.out to flash memory.
82497 bytes downloaded into FLASH (4.69 Kbytes/sec)
Flash loading completed successfully.
Loaded debugee: C:\Users\nharel\Dev\XXXX\Env\Debug\Exe\XXXX.out
Target reset
Loaded custom formats file: C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.3\arm/config/custom_formats.dat
Loaded custom formats file: C:\Users\nharel\Dev\XXXX\Env/custom_formats.dat
Session started

I also have no idea what's those custom_formats.dat are for. The one in my project "XXXX\Env" doesn't even exist.

[NicolasHDD]

Ok just figured you have to use a driver in the arm\bin folder and remove the "arm prefix". So if you want armproc.dll to be loaded, you just type:
"driver": "proc",

The VS code suggestions are false. Still not working though, can't seem to load the driver anyway:

[micaelbo]

We are aware about problems related to limitations in the v8 IDE. If possible, please upgrade to the latest IAR Embedded Workbench Arm v9.30!

Further, when it comes to the error message "Unable to recognize driver", only the driver names reported back by VS Code as "Valid values", are possible.

[VzdornovNA88]

it's sad to hear

[NicolasHDD]

We are aware about problems related to limitations in the v8 IDE. If possible, please upgrade to the latest IAR Embedded Workbench Arm v9.30!

Ok so this is an issue related to IAR 8 then. That was not mentioned in this topic. Thank you for the info. Any plan on making the extension compatible with IAR 8 then ? If not, then maybe, would it be possible to at least modify the following line so people don't waste time trying to figure out what is wrong with their setup ?

Further, when it comes to the error message "Unable to recognize driver", only the driver names reported back by VS Code as "Valid values", are possible.

Some of them are not working.

Ex:

Edit: It seems the TI XDS value error is also an issue that only pops up while using IAR 8.

[andrewtkh1]

@NicolasHDD Apologies as I've since left the company and no longer have access to an IAR license. I will try to get a colleague to see if he is able to help with this as if I recall correctly, he was somehow able to get the debug mode working with IAR v8.

[VzdornovNA88]

I will also be waiting for this information

[mario-pi]

Apologies for the late response, we have limited development capacity during the summer break.
We have unfortunately found a bug in the 8.x versions of EWARM which prevents debugging in VSCode and are working on it.

[VzdornovNA88]

I thought I needed to add special driver stub for st-linkv2 to iar_vs_code debugger extension because my main problem is the "...unavailable driver..." in message from this extension. Is there also a problem of the process of communication with spy debugger or apps which are compiled by 8.x versions iar ? if these apps are just not compatible with new tool spy debugger on ABI level,it will be terrible.

[mario-pi]

I thought I needed to add special driver stub for st-linkv2 to iar_vs_code debugger extension because my main problem is the "...unavailable driver..." in message from this extension. Is there also a problem of the process of communication with spy debugger or apps which are compiled by 8.x versions iar ? if these apps are just not compatible with new tool spy debugger on ABI level,it will be terrible.

The "Unsupported transport" error in this issue is due to a backend bug in the C-SPY debug session setup, independently of the probe driver being used. The fact that some of the drivers won't load is instead caused by a separate issue, which should be on the VSCode client side.

[ycsin]

@andrewtkh1 Since it's working for you, can you tell me which driver you're using ?

It is using "stlink2" as "driver"

[mario-pi]

The backend bug which causes the "Unsupported transport" issue has been fixed in EWARM 8.50.5 and onwards.

We are going to update the compatibility README accordingly. We anyway recommend to use the latest EWARM 9.30 for better performance with VSCode.

[VzdornovNA88]

Thanks, so it's a good news for us, maybe I can consider changing the version to 8.5.

[mario-pi]

We are aware about problems related to limitations in the v8 IDE. If possible, please upgrade to the latest IAR Embedded Workbench Arm v9.30!

Ok so this is an issue related to IAR 8 then. That was not mentioned in this topic. Thank you for the info. Any plan on making the extension compatible with IAR 8 then ? If not, then maybe, would it be possible to at least modify the following line so people don't waste time trying to figure out what is wrong with their setup ?

Further, when it comes to the error message "Unable to recognize driver", only the driver names reported back by VS Code as "Valid values", are possible.

Some of them are not working.

Ex:

Edit: It seems the TI XDS value error is also an issue that only pops up while using IAR 8.

Thank you for taking time to report this. The "Unable to recognize driver" is a separate issue from "Unsupported Transport", and might be due to a driver name incompatibility between IAR 8.x and 9.x. Would it be possible for you to open a separate issue for it, so that we can close this one and we can continue discussing it there?

EDIT: Apologies, I didn't notice that there was already an issue filed for this. We can continue discussing the st-link problem at #9 . Thanks.

[NicolasHDD]

The backend bug which causes the "Unsupported transport" issue has been fixed in EWARM 8.50.5 and onwards.

We are going to update the compatibility README accordingly. We anyway recommend to use the latest EWARM 9.30 for better performance with VSCode.

Great news guys =) Thank you for efficiency, I know it's not easy during the summer break.

[HampusAdolfsson]

This error occurs when we connect to the debugger to fetch variables. I'll add a workaround so that you can still start a debug session with EWARM 8.4, but there will be no variables in the debugger view.

As mentioned, the recommended solution is still to use EWARM 8.50.5 or later.

[VzdornovNA88]

@HampusAdolfsson, What do you think about EW since version 8.2. Will your fix solve this problem for this version or is it impossible?

[HampusAdolfsson]

@VzdornovNA88 This fix will only help with version 8.4. Earlier versions of EW do not have some important features that we need for VS Code integration.

[HampusAdolfsson]

We just released 1.10.4 which includes a fix for this error. As mentioned, there will be no variables in the variables window, but you should now be able to start a debug session with EWARM 8.4.