Hi guys,

I am facing an issue when starting the debugging. Although compilation is relatively quick, the process of starting the debugging takes very long about few minutes.

CPU : STM32F429ZI
Debugger : ST-link

Appreciate if somebody could guide me on this.

Thanks for the report.

Can you confirm if you are running Debug > Start Debugging, or Debug > Attach to Process?

If I select Start debugging,
after compilation, it takes a long time to start the programmer and after programming it takes similar or longer time to activate the debugger.

However, after programming, attach to the process is faster.

Thanks for confirming the actions, and its the build process which is taking a long time from your report.

This is due to how the <SrcWrapper.h> is added as part of the build process, which causes the Deep Search to assess a large number of files every build.

The Build process can be faster, by Disabling the Compiler > Deep Search option, BUT you will need to add in the SrcWrapper.h and all other library and header files which need to be included.

[code]
// Top of Main Sketch INO File
// Avoid Official STM32 Build Time: --> Add these #includes, and all other library headers, then disable vMicro > Compiler > Deep Search
#include <SrcWrapper.h>
[/code]

Thank you, Simon for the quick response.

I am sure it is not the build process that is delaying (although there is a high chance I am ignorant about the process), because

First build takes takes about 100 secs and subsequent builds takes around 17secs.

However, the time after that to connect to the Stlink long (around few minutes). This happens even for just "build and upload" alone.

[Code]
Program MnC2test size: 115,240 bytes (used 5% of a 2,097,152 byte maximum) (112.21 secs)
Minimum Memory Usage: 47772 bytes (24% of a 196608 byte maximum)

# Copy build result to 'Project>Property Pages>Intermediate Directory'
# Destination: file:///D:/xxxx/MnC2test/Debug/

Uploading 'MnC2test' to 'Nucleo-144' using 'COM1'
Uploader started for board Nucleo-144
Upload method will be: bootloader
Uploading via Bootloader
C:\arduino-1.8.13\portable\packages\STM32\tools\STM32Tools\1.4.0\tools\win\stm32CubeProg.bat 0 "C:\Users\simma\AppData\Local\Temp\VMBuilds\MnC2test\STM32_~1\Debug/MnC2test.ino.bin" -g
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.4.0                  
      -------------------------------------------------------------------[/Code]

Also, I just got a prompt from VS2019 about VM being unresponsive. I am attaching the screenshot for your reference.

---

Thanks for the detail, and the uploader in use here seems to be the STM32Cube Programmer via Serial, which is part of the core package.

Is this faster if you select the "STLinkv2.1 + OpenOCD (vMicro)" as the uploader?
(This will use OpenOCD to connect to the STLink and upload the code via the programmer)

But the selection is  STM32Cube Programmer (SWD). Anyway, I will try as suggested.

Hi, I tried as suggested, but the results are the same. For some reason Serial upload is auto selected. I am attaching the screenshot for your reference.

---

Thanks for the update.  I was trying to understand if the issue is the core tools, or whether it is something else.

This has failed to program the board via the programmer, so I would expect this to be faster than when it is programming successfully via the STM32 Cube Programmer.

Can you confirm if this failed upload, was as slow as the previous ones? (around a minute)

It has failed to program.

If I choose STlink (SWD), although it took a long time but it programmed the chip.

Can you confirm if the failed upload via the vMicro OpenOCD option was as slow as the previous ones? (around a minute)

Does the upload via the STLink (SWD) report progress during the upload? (or just appear to hang)

>>Can you confirm if the failed upload via the vMicro OpenOCD option was as slow as the previous ones? (around a minute)

Yes.

>>Does the upload via the STLink (SWD) report progress during the upload? (or just appear to hang)


Code (]ST-LINK FW  : V2J37S7
Voltage     : 3.25V
SWD freq    : 4000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x419
Device name : STM32F42xxx/F43xxx
Flash size  : 1 MBytes
Device type : MCU
Device CPU  : Cortex-M4
Memory Programming ...
Opening and parsing file: MnC2test.ino.bin
  File          : MnC2test.ino.bin
  Size          : 76760 Bytes
  Address       : 0x08000000
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 4):

Download in Progress: File download complete Time elapsed during download operation: 00:00:02.817      The upload process has finished. # Copy build result to 'Project>Property Pages>Intermediate Directory' # Destination: file:///D:/xxxx/MnC2test/Debug/ RUNNING Program ...   Address:      : 0x8000000 Warning: The core is halted Start operation achieved successfully

VS prompting as "VM is unresponsive" and asks if would like to disable the extension.

This is not a show stopper. But may give you a hint.

Please advise.

Thanks for confirming the vMicro failed upload took as long, which is odd as it should fail virtually instantly.

The "unresponsive" prompt will be due to vMicro waiting on the upload process to complete, but it is not our code running at this point.

The upload snippet above shows a time elapsed of 2.817s, but your experience is the upload alone is taking > 1minute?
(use the vMicro > Uploader > Upload Last Build to test upload in isolation)

Is it the same in the Arduino IDE using the same sketch and programming method?

Apologies if repeat questions, I'm just trying to make sure I understand the issue fully.

Hi,

>>The upload snippet above shows a time elapsed of 2.817s, but your experience is the upload alone is taking > 1minute?
(use the vMicro > Uploader > Upload Last Build to test upload in isolation)
The process takes > 1min to start the programmer. But actual programming is fast (2-3sec). If I choose Debug, it takes > 1min after programming process. Most of the time it will fail to debug. I can debug only by "attach to the process" method.

>>Is it the same in the Arduino IDE using the same sketch and programming method?

In Arduino IDE, it is quicker. Programmer starts immediately.

Thanks for the detail.

Debug > Start - This will take around a minute as it rebuilds the solution, and re-uploads it.
Debug > Attach - This should be quick to attach once programmed, and only attaches the debugging process.

Could you follow the steps below to reveal further information for us:
1) Add the attached entries to a board.txt in your project (Right click project in Solution Explorer > Add > Local Board.txt) and Restart VS
2) Set the Compiler > Verbose, and Compiler > Show Build Properties
3) Perform the "Build and Upload" process.
4) After this please attach the BuildTimings.txt file it generates, and the entire Build Output

---

I am attaching the BuildTimings.txt for your review. I have done both "clean, build and upload" and "build & upload".

---

Thanks for the timings and detail.

Could you please also attach the output from Output Window, for a build and upload?  (with the settings set as shown at the top of the page)

I am attaching the BuildTimings.txt, build.txt for you review.

---

There is some improvements. I can program immediately if I commnet out the

"recipe.hooks.postbuild.2.pattern=notepad.exe {ProjectDir}BuildTimings.txt"

This was tested on Win 7. I will check with other Win 10.

There is another issue with Debug. I cannot "Start debug" but only "Attach to Process".

Any Idea, why?

Thanks for the detail, and without the build hooks there was an issue previously.

The delay added by the Build Timing hook is expected, though the COM Port has also changed from COM1 to COM5.

Looking at the timings there is no longer the 2 minute delay between build completion and upload start. The board.txt can be removed from the project now we have the timings.

Can you confirm:
If you remove the board.txt and leave the selected COM port on COM5 - its OK for Build + Upload?
If you put it back to COM1 - its slow to Build + Upload?

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

[code]# MI Debugger Properties
{
  "serverLaunchTimeout": 5000,
  "filterStdout": false,
  "filterStderr": true,
  "targetArchitecture": "arm",
  "stopAtEntry": false,
  "externalConsole": false,
  "MIMode": "gdb",
  "MIDebuggerServerAddress": "localhost:3333",
  "cwd": "C:\\Users\\simma\\AppData\\Local\\Temp\\VMBuilds\\MnC2test\\STM32_Nucleo_144\\Debug",
  "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 \"{C:\\Users\\simma\\AppData\\Local\\Temp\\VMBuilds\\MnC2test\\STM32_Nucleo_144\\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": "C:/Users/simma/AppData/Local/Temp/VMBuilds/MnC2test/STM32_Nucleo_144/Debug/MnC2test.ino.elf",
  "logging": {
    "moduleLoad": false,
    "trace": false,
    "engineLogging": false,
    "programOutput": false,
    "exceptions": false,
    "traceResponse": false
  },
  "visualizerFile": "C:\\Users\\simma\\AppData\\Local\\Temp\\VMBuilds\\MnC2test\\STM32_Nucleo_144\\Debug\\debugger_tmp.natvis",
  "showDisplayString": true
}[/code]

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.

Thanks for explaining the differences between your environments.

The additional in board.txt for the toolchain is required due to the variety of STM32 cores available for the Arduino Ecosystem.

Please confirm: The original issue reported is the delayed programming, which from the logs has gone away at least on one of your machines?

Hi,

Win 7 machine, delay is not apparent.

However, Win 10 machine there is no improvement. I tried both on VS 2017 & 2019. Same results. I am attaching the files for your review.

[code]VS 2019 W10
==========================================
Sat 05/12/2020 21:41:09.24      Build Start
==========================================
Sat 05/12/2020 21:41:22.69      Core Start
Sat 05/12/2020 21:41:22.88      Core End
Sat 05/12/2020 21:41:23.02      Lib Start
Sat 05/12/2020 21:41:23.69      Lib End
Sat 05/12/2020 21:41:23.85      Sketch Start
Sat 05/12/2020 21:41:25.21      Sketch End
Sat 05/12/2020 21:41:25.33      Prelink Start
Sat 05/12/2020 21:41:26.76      Prelink End
Sat 05/12/2020 21:41:26.88      ObjCopy Start
Sat 05/12/2020 21:41:27.07      ObjCopy End
Sat 05/12/2020 21:42:00.22      Upload Start
Sat 05/12/2020 21:42:06.04      Upload End
==========================================
Sat 05/12/2020 21:43:13.04      Build Start
==========================================
Sat 05/12/2020 21:43:26.38      Core Start
Sat 05/12/2020 21:43:26.61      Core End
Sat 05/12/2020 21:43:26.69      Lib Start
Sat 05/12/2020 21:43:27.54      Lib End
Sat 05/12/2020 21:43:27.70      Sketch Start
Sat 05/12/2020 21:43:29.07      Sketch End
Sat 05/12/2020 21:43:29.26      Prelink Start
Sat 05/12/2020 21:43:30.63      Prelink End
Sat 05/12/2020 21:43:30.92      ObjCopy Start
Sat 05/12/2020 21:43:31.15      ObjCopy End
Sat 05/12/2020 21:44:32.24      Upload Start
Sat 05/12/2020 21:44:38.04      Upload End

VS 2017 W10
==========================================
Sat 05/12/2020 21:52:28.83      Build Start
==========================================
Sat 05/12/2020 21:53:21.36      Core Start
Sat 05/12/2020 21:53:21.44      Core End
Sat 05/12/2020 21:53:21.50      Lib Start
Sat 05/12/2020 21:53:22.21      Lib End
Sat 05/12/2020 21:53:22.29      Sketch Start
Sat 05/12/2020 21:53:23.58      Sketch End
Sat 05/12/2020 21:53:23.67      Prelink Start
Sat 05/12/2020 21:53:24.94      Prelink End
Sat 05/12/2020 21:53:25.03      ObjCopy Start
Sat 05/12/2020 21:53:25.20      ObjCopy End
Sat 05/12/2020 21:54:07.71      Upload Start
Sat 05/12/2020 21:54:13.04      Upload End
==========================================
Sat 05/12/2020 21:56:05.71      Build Start
==========================================
Sat 05/12/2020 21:56:19.27      Core Start
Sat 05/12/2020 21:56:19.37      Core End
Sat 05/12/2020 21:56:19.43      Lib Start
Sat 05/12/2020 21:56:20.13      Lib End
Sat 05/12/2020 21:56:20.20      Sketch Start
Sat 05/12/2020 21:56:21.47      Sketch End
Sat 05/12/2020 21:56:21.57      Prelink Start
Sat 05/12/2020 21:56:22.82      Prelink End
Sat 05/12/2020 21:56:22.89      ObjCopy Start
Sat 05/12/2020 21:56:23.05      ObjCopy End
Sat 05/12/2020 21:58:22.40      Upload Start
Sat 05/12/2020 21:58:28.04      Upload End
[/code]

---

Hi Simon,

Were you able to look at the build output and conclude anything?

Thank you.

Is there anything on COM5 on the Win10 Machine?

Can you attach the same log from the working Win7 Machine for comparison?

We are not aware of any issues on Win10 starting the debugging process, as we have a Win10 Machine in our development environment which does not display this issue.

There is a USB-Serial converter on COM5. I will remove that and try.

I tried after physically removing COM5. But no improvement.

Appreciate if you could explain about the following. I select SWD as the programming method. However I notice the following in the Micro Build output. Why is it stating upload method will be bootloader?

[code]
Uploading 'MnC2test' to 'Nucleo-144' using 'COM5'
recipe.hooks.deploy.preupload.1.pattern
cmd.exe /c ECHO %DATE% %TIME%      Upload Start >> D:\1\MnC2test\BuildTimings.txt
Uploader started for board Nucleo-144
Upload method will be: bootloader
Uploading via Bootloader
C:\arduino-1.8.13\portable\packages\STM32\tools\STM32Tools\1.4.0\tools\win\stm32CubeProg.bat 0 "C:\Users\simma\AppData\Local\Temp\VMBuilds\MnC2test\STM32_~1\Debug/MnC2test.ino.bin" -g[/code]

Thanks for the update, and just wanted to ensure the device on the COM port wasn't causing the delay.

The reason it says "bootloader" is due to the programmers in this core being on the boards menu, instead of being configured as programmers as is normally done for the Arduino platforms.

So just to recap:

• Both tests use the same physical board + programmer 
  
• Both machines have same VS, VMicro, Arduino versions
  
• Win10 machine has the 1min delay between compile and upload
  
• Win 7 machine has no delay between compile and upload
  

Yes, confirm.

Would it be possible to attach the Arduino IDE log for an upload through the same programmer?