"SVD: No active debug sessions or no SVD files specified" on Windows with the official svdFile from STM32CubeIDE feeded

[Bokgu]

I have an issue on one of my project (through VSCode plugin).

On MAC OS and Unix system one of my colleague seem to have SVD parsing functional and information about device peripheral but for all other developers on Windows we have this message (see caption) and no other informations nor popup.

However if we give a bad file path for SVD file, with the vsdFile property, we'll still get an error from VSCode on Windows even if no peripherals charged.

Could you look into this please ?

[Bokgu]

Exactly here what should function and does not :

And here if we put a bad path :

Best Regards, Vincent

[haneefdm]

I am not understanding your question/comments.

Are you saying that on Windows you get an error message due to ${workspaceRoot} but the same thing works properly on Mac/Linux?

[Bokgu]

@haneefdm the problem is not coming from ${workspaceRoot} as we can see on the second picture that VSCode is evaluating this variable to find the path in the little popup of the 2nd picture :

The problem comes when I have no error on popup (meaning it has found and digested the file pointed by vsdFile property ?) but I still have this annoying feedback (happenned for me and several others on Windows but a collegue on MAC OS had it work with exactly the same VSD file) :

Vincent

[haneefdm]

You mean the entire issue is about this message? I still don't understand

[Bokgu]

Yes, that's basically the problem I encountered with some work colleagues. It doesn't give me access to the peripheral view mainly

[haneefdm]

Maybe my brain is not functioning today. You saw the message about the ENOENT: No such file or directory error (file not found). Meaning there is no svd file (according to the extension). So, is the file there or not? That error message means we could not digest that file. So....

[Bokgu]

@haneefdm the SVD file is here and the official file from STM32CubeIDE

The exemple with ENOENT: No such file or directory error was just only here to show the file was present and processed by cortex-debug in comparism to the seemingly inert processing in my first picture.

Best Regards

[haneefdm]

What are the contents of the Debug Console with login enabled (instructions printed in Debug Console). I am not sure the state of the debugger. It appears paused?

Also, can you attach (compressed) the svd file.

[haneefdm]

Also, what version of cortex-debug are you using? Can you try the pre-release 1.5.1 (available within VSCode but you have to enable it) before we move forward.

[Bokgu]

Hi back @haneefdm,

Here all the info you asked with the logs based on pre-release 1.5.1 runs.

SVD_issue.tar.gz

Best Regards, Vincent

[haneefdm]

No output from the Debug Console?

[Bokgu]

Output from Debug Console are written into these 2 files

[erektuserektus]

I have same issue. With correct svd path, I have message that no svd file is specified, but no error is showed. If I set wrong path, I get error message file not found. Strange is that first vscode start and first debug shows peripheral list. Second debug run is without peripherals list.

[haneefdm]

@erektuserektus Thanks. So this happens to you in your second session. That is a bit different. Can you provide the following details

• Version of Cortex-Debug
• OS Type: (Windows, Mac, Linux, WSL, etc.)
• A compressed copy of your SVD file (or a link to it)
• Your launch.json

[haneefdm]

@erektuserektus Just to confirm. You ended the first session and then started the second session and it ended normally. Then you started the second session and you see the wrong behavior?

If you wait for a second or so to start the second session, does this still happen?

I believe what you & @Bokgu are saying but I don't understand it. What @Bokgu says seems like it happens every time on Windows only and that, I fail to comprehend entirely. Failing on the second session, that I can see happening - very unlikely but could be a timing or VSCode API issue.

Keenly awaiting responses.

[stanczyk4]

Im also experiencing the same. Issue. Valid svd downloaded from STMicros official site, using "svdFile": "${workspaceRoot}/STM32F103.svd" as the argument, the file is found. If im in a debug session, i get SVD: no active debug sesssion or no svd files specified.

EDIT: I closed and re-opened the vscode folder, and it worked fine. Randomly after a few debug sessions it stopped (0 files were changed between working and not working)

[haneefdm]

Please, please provide details as this is so elusive. It may seem very obvious to you but not to me who is trying to duplicate the issue.

• Version of Cortex-Debug
• OS Type: (Windows, Mac, Linux, WSL, etc.)
• A compressed copy of your SVD file (or a link to it). Please
• Your launch.json
• Steps to reproduce, if you can please

EDIT: I closed and re-opened the vscode folder, and it worked fine. Randomly after a few debug sessions it stopped (0 files were changed between working and not working)

This is even more confusing.

Note that I don't have an army of people taking care of this extension. It is just me and I have a day job.

[stanczyk4]

Sorry, was trying to mention that its happening to more than one person. Ive had this issue on and off for the last month, havent needed the svd info as much though so have ignored it.

Im struggling to recreate this, when it happens to me again ill try to gather more info.

Version of Cortex-Debug - 1.4.4 OS Type: Windows 10 SVD file - https://www.st.com/resource/en/svd/stm32f1_svd.zip the f103 one. Your launch.json

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
        {
          "name": "jlink",
          "type": "cortex-debug",
          "request": "launch",
          "servertype": "jlink",
          "cwd": "${workspaceRoot}",
          "executable": "${command:cmake.launchTargetPath}",
          "device": "STM32F103RC",
          "interface": "swd",
          "runToEntryPoint": "main",
          "serverArgs": [
            "-gui",
          ],
          //   "rtos": "FreeRTOS",
          "svdFile": "${workspaceRoot}/STM32F103.svd",
          "rttConfig": {
              "enabled": true,
              "address": "auto",
              "decoders": [
                  {
                      "port": 0,
                      "type": "console",
                      "inputmode": "raw",
                      "timestamp": true
                      // "logfile": "${workspaceFolder}/build/rtt_log.txt"
                  }
              ]
          }
      },
      {
          "name": "(Windows) Launch",
          "type": "cppvsdbg",
          "request": "launch",
          "program": "${command:cmake.launchTargetPath}",
          "args": [],
          "stopAtEntry": false,
          "cwd": "${workspaceFolder}",
          "environment": [],
          "console": "externalTerminal"
      }
  ]
}

[stanczyk4]

Just had it happen. v1.4.4. Same info as previous comment. No file changes. I debugged to main, continued, paused, reset, svd file no longer loading.

All reset's or re-debugging after it happens once also fail to load the svd file. Reloaded vscode multiple times and did not fix it. Updated to the pre-release 1.5.1 and reloaded the app through the reload window button, and it worked again.

Attaching terminal and debug console output when it failed to load.

EDIT: Attempted to make it fail on 1.5.1 with no success. Switched back to 1.4.1 and tried to make it happen, couldnt, while the debugger was starting i right clicked a file and closed all and in that debug session it happened again. (doesnt seem likely correlated? but that was the only difference to what i was doing).

Still no success making it happen in 1.5.1

terminal_post_debug_with_no_svd_info.txt

[erektuserektus]

Stanczyk description is exactly same as I can see. I have just difficulty to start VScode with working Cortex peripherals. It worked for me just once. Because I'm new with VScode, I changed launch.json so often to try to make it work so I don't have nice "history" for working/not working state. I'm using also Embedded IDE extension v3.7.1. it is true that EIDE informs me that it has difficulty with parsing my launch.json and I can't find reason for that, but it also said it when Cortex peripherals worked. So I don't know what's wrong.

My setup: Cortex-debug V1.4.4

launch.json

{ "version": "0.2.0", "configurations": [ { "cwd": "${workspaceRoot}", "executable": "./build/Test/Test.elf", "name": "Debug Microcontroller", "request": "launch", "type": "cortex-debug", "servertype": "jlink", "serverpath": "C:/Program Files/SEGGER/JLink/JLinkGDBServerCL.exe", "armToolchainPath": "C:/Program Files (x86)/GNU Arm Embedded Toolchain/10 2021.10/bin", "device": "M481SG8AE2A", "interface": "swd", "serialNumber": "", // add J-Link serial number if having multiple attached the same time. "runToEntryPoint": "main", "svdFile": "${workspaceRoot}/M481_v1.svd", } ] }

SVD file: M481_v1.zip

list from debug console Reading symbols from C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10\bin\arm-none-eabi-objdump.exe --syms -C -h -w C:\Tomas\Keil\Test\build\Test\Test.elf Reading symbols from c:/program files (x86)\gnu arm embedded toolchain\10 2021.10\bin\arm-none-eabi-nm.exe --defined-only -S -l -C -p C:\Tomas\Keil\Test\build\Test\Test.elf Launching GDB: "C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10\bin\arm-none-eabi-gdb.exe" -q --interpreter=mi2 "C:\Tomas\Keil\Test\build\Test\Test.elf" Set "showDevDebugOutput": true in your "launch.json" to see verbose GDB transactions here. Helpful to debug issues or report problems Launching gdb-server: "C:/Program Files/SEGGER/JLink/JLinkGDBServerCL.exe" -singlerun -nogui -if swd -port 50000 -swoport 50001 -telnetport 50002 -device M481SG8AE2A Please check TERMINAL tab (gdb-server) for output from C:/Program Files/SEGGER/JLink/JLinkGDBServerCL.exe Finished reading symbols from objdump: Time: 388 ms Finished reading symbols from nm: Time: 328 ms C:\Program Files (x86)\GNU Arm Embedded Toolchain\10 2021.10\bin\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory. Reading symbols from C:\Tomas\Keil\Test\build\Test\Test.elf... AFE_SPIDone () at ./Source/src/AFE.c:268 268 { Program stopped, probably due to a reset and/or halt issued by debugger 2 Resetting target

Temporary breakpoint 1, main () at ./Source/src/main.c:123 123 System_Init(); / Init System, IP clock and multi-function I/O /

[stanczyk4]

@erektuserektus can you try the v1.5.1 pre release? Since it seems to happen more consistently for you I'm curious if it's been fixed in that version. I haven't got it to happen in 1.5.1 but it's also too random to know for sure

[erektuserektus]

I've switched to 1.5.1 and it looks like it works without any issue. I've tried several debug sections, restart VS tried again and no issue found. I haven't done any source code or setting modification, just upgrade and did tests. In compare to previous version, I can see in Cortex Peripherals window label that SVD file is being loaded during debug start. This doesn't happen for previous version.

[haneefdm]

Please install the latest build from https://github.com/Marus/cortex-debug/releases (v1.5.2-pre1) Please provide feedback.

The way I see it is there one condition that not handled.

• VSCode assigns a unique ID (GUID) to each debug session. We rely on this as we support multiple concurrent debug sessions (imagine multi-core). It is not supposed to re-cycle them but if it does, then we had a problem
• If the previous session did not really terminate properly, then we could also have issues

If both of the above happened, then there was no error message or notification. It was silently ignored. Now, there is an error message -- marked as internal errors as it should never happen. I also added other guards (error messages) in case problems still persist.

There are other changes in this build (support for uC/OS-II visualization).

Note 1.5.x is a precursor to 1.6.0 and I do not have a schedule for it. It will be release as 1.5.2 in the marketplace though and will be available for people who enabled pre-releases. All ODD minor numbers are pre-releases as per MS rules for extensions.

[haneefdm]

Thank you for everyone who contributed and helped me.

Also, btw the Embedded IDE extension v3.7.1 is unrelated to us and I don't know why they would be parsing the launch configuration(s) meant for our debugger.

[haneefdm]

If 1.5.1/1.5.2-pre1 solves this issue, I would like to close this issue. Any objections?

We do not wait for a public release for an issue to be closed.

[stanczyk4]

I haven't seen the issue since going to 1.5.1