[dabramson]

The setting that triggers the issue is under project property pages, Configuration Properties->General->Generate a test container file (see screenshot).

When it is set to yes, <SolutionDir>VisualGDB\<BuildConfig> directory must exist BEFORE building. Otherwise the build does not work, and you get the exception from the original post.

If I delete the directory and build with this setting, the build fails. If I delete only the CONTENTS of the directory and build with this setting, the build passes.

I watched the contents of the empty directory while building, and the .vgdbtestcontainer file gets placed there before any of the linker outputs. So there is an obvious work around for CI builds (pre-create <SolutionDir>VisualGDB\<BuildConfig> if it isn’t there). But there is a fairly trivial (in my view) issue here where turning on a setting causes a failure because a file is being placed in a directory that may not exist, and there is nothing to create the directory if it doesn’t exist.

I’ve used this setting in the past an not had this issue. I did note that the contents of the file are now xml, whereas this tutorial , at step 21, says it is just a text file…so there appears to be some kind of change in this area.

Attachments:

You must be logged in to view attached files.

[dabramson]

ok. I removed the toolchain from visualgdb, and then imported again with the version that the others had, and now I have the same 5.x id.

I’m glad there is a workaround, but it is a little concerning that different versions of VGDB will end up “seeing” (for lack of a better term) the same toolchain differently. So there is potential that someone who joins the project later, after we’ve all upgraded visualgdb again, will setup their environment and get a different ID for the toolchain. Is there a different way to manage the toolchain across the team that doesn’t have this issue?

[dabramson]

I found that I was still using armcc with the tutorial project. The errors I got in my previous post where following the tutorial exactly as shown (except I used armcc instead of armclang).

I changed the tutorial project to armclang and now it builds. For sanity I switched it back to armcc to make sure it was still broken…but it wasn’t. So switching to armclang seems to have unstuck something. Very strange.

 

 

• This reply was modified 2 years, 11 months ago by dabramson.

[dabramson]

Hello,

I ask keil and they of course want more information. In an attempt to do that, I tried to go back and just do the tutorial exactly as it is presented in the hopes that I’d see the same undefined symbols at the link step. Unfortunately, the tutorial won’t compile after step 13. I undid everything back to step 10, and it built again.

I did step 11 only. It still builds, but with these warnings…

"C:/Users/dabramson/AppData/Local/VisualGDB/EmbeddedEFPs/Profiler/FastSemihosting.cpp", line 76: Warning: #550-D: variable "pSemihostingStruct" was set but never used
void *pSemihostingStruct = &s_FastSemihostingState;
^
C:/Users/dabramson/AppData/Local/VisualGDB/EmbeddedEFPs/Profiler/FastSemihosting.cpp: 1 warning, 0 errors
"C:/Users/dabramson/AppData/Local/VisualGDB/EmbeddedEFPs/Profiler/TestResourceManager.h", line 322: Warning: #1-D: last line of file ends without a newline
#endif
^
"C:/Users/dabramson/AppData/Local/VisualGDB/EmbeddedEFPs/Profiler/TestResourceManager.cpp", line 305: Warning: #1-D: last line of file ends without a newline
#endif

Then I did step 12. And it doesn’t compile…with these errors:

"main.h", line 41: Error: #5: cannot open source input file "stm32f4xx_hal.h": No such file or directory
#include "stm32f4xx_hal.h"
^

 

Then I do step 13 and get these errors:

"C:/Users/dabramson/AppData/Local/Arm/Packs/Keil/STM32F4xx_DFP/2.15.0/Drivers/CMSIS/Device/ST/STM32F4xx/Include/stm32f407xx.h", line 167: Error: #5: cannot open source input file "core_cm4.h": No such file or directory
#include "core_cm4.h" /* Cortex-M4 processor and core peripherals */
^
RTE/Device/system_stm32f4xx.c: 0 warnings, 1 error
Failed to compile system_stm32f4xx.c. armcc.exe exited with code 1

I’ve attached a zip of my project after step 13.

 

• This reply was modified 2 years, 11 months ago by dabramson.

Attachments:

You must be logged in to view attached files.

[dabramson]

Thanks!

The link is now downloading 5.6.1.4071, which I’m assuming is the beta listed on the main download page.

1. Does that beta also have the combined data from multiple live vars change?
2. I’m mid-project so very hesitant to try beta anything at this point, can the link be fixed to still give 5.5.104.3945? I’m currently on 5.5R4 (build 3920) so would be more comfortable trying the build mentioned above.

 

[dabramson]

The toolchain with arm-none-eabi-gdb.exe was downloaded through visual gdb. Do you not support those toolchains? If not where can I go for support on that?

 

[dabramson]

Is gdb exiting because of the dropped telnet connection? Why would that happen? Should I check with my IT dept?

[dabramson]

One strange thing to note in the logs above is that it mentions there being a breakpoint at the first line in main. I do not have a breakpoint set there. This is not the main problem, just some information.

[dabramson]

remaining two files mentioned above

Attachments:

You must be logged in to view attached files.

[dabramson]

I captured all the logs I know to capture. I don’t see anything obvious. Please help.

Four files in this post. Two more files coming in next post.

openocd-tab in file name references which openocd tab in the error window (see png) the text was pulled from

 

Attachments:

You must be logged in to view attached files.

[dabramson]

Here is a little additional info. I’m not sure if it is related.

After I posted last I tried removing and re-adding the OpenOCD package…that did not help. The debugging session still stopped after a few minutes.

Next I went to uninstall and reinstall VisualGDB. That gave me an error saying that a program called VcxprojReader had to be closed. Instead of continuing the uninstall I went to kill that program through Task Manager. There were 3 instances running. I killed them all through Task Manager. Now I have a debugging session that has been running for about 1 hour.

If the unexpected stop happens again, I’ll look for this process and kill it.

In the meantime…is that program even related to VGDB, or is this just a coincidence?

[dabramson]

I finally got this working by calling InitializeInstrumentingProfiler (as directed by the error message), I was calling InitializeSamplingProfiler.

 

[dabramson]

As it turns out, our IT contacted me to tell me they were going to whitelist it for me. So no problem here.

 

Thanks

[dabramson]

Hi,

I updated visual gdb as suggested and I can now debug unit tests again.

That said, the first time I went to debug with the new VGDB webroot detected vgagent.exe (running out of the Visual GDB Program Files) as a threat and blocked it. I had to tell webroot that it was ok to let it run. I’m not sure what vgagent does, but you probably don’t want it getting flagged by virus/malware scanning software.

Thanks,

Dave

[dabramson]

1. That is what we are currently doing. It is not ideal because it requires every team member to check out the project’s vgdbcmake file to make what is essentially a non-change (they will end up importing the toolchain with the same ID as is already present in the .vgdbcmake file). Importing a toolchain shouldn’t need to change project specific files. Changing a project to use an already imported toolchain would obviously need to touch the vgbdcmake file though.
2. Wouldn’t that also require manually editing FindToolchain.props in order for VGDB to correctly find the toolchain under the ID that you manually changed to in the Toolchain.xml?

[Author]

Posts