In my desperation to find the solution, I trying them on different PCs with two different OS (Win 7 and Win 10). So there is the difference in the COM numbers.
The timing results I posted earlier is for Win 7 PC.
Now I am trying on the Win 10 PC. I will post the results.
I started to feel that it may be process control of VS while receiving from VM.
The reason being, after the delayed programming, I can debug by "Attach to Process" method.
And I have to specify the "tools.stlinkv2.path={runtime.tools.xpack-arm-none-eabi-gcc.path}/bin" in the board.txt.
Otherwise VS complains "Unable to start debugging. The value of miDebuggerPath is invalid". Although the Micro Build shows the following
# MI Debugger Properties
{
"serverLaunchTimeout": 5000,
"filterStdout": false,
"filterStderr": true,
"targetArchitecture": "arm",
"stopAtEntry": false,
"externalConsole": false,
"MIMode": "gdb",
"MIDebuggerServerAddress": "localhost:3333",
"cwd": ebug",
"MIDebuggerPath": "{runtime.tools.arm-none-eabi-gcc.path}/bin\\arm-none-eabi-gdb.exe",
"MIDebuggerArgs": "",
"debugServerPath": "C:\\ProgramData\\vmicro\\tools\\openocd-0.10.0.20200213\\bin/openocd.exe",
"debugServerArgs": "-d2 -l \Debug/MnC2test.ino_DebugOpenOCD.log}\" -s \"C:\\ProgramData\\vmicro\\tools\\openocd-0.10.0.20200213/scripts/\" -f \"interface/stlink.cfg\" -f \"target/stm32f4x.cfg\" -c \"init\"",
"program": test.ino.elf",
"logging": {
"moduleLoad": false,
"trace": false,
"engineLogging": false,
"programOutput": false,
"exceptions": false,
"traceResponse": false
},
"visualizerFile": ebug\\debugger_tmp.natvis",
"showDisplayString": true
}
Sorry for the persistent nagging. I am trying to setup my systems to use STLink and J-Link debuggers for a project I am starting. Just for your info, on the Win 10 PC, I can debug using STLink under VSCode/PlatformIO combination without any issues.