[support]

Hi,

Thanks, this looks like the hang is related to VisualGDB. Could you please let us know the exact VisualGDB build (from VisualGDB.exe file properties) so that we could pinpoint this further?

Please also try manually killing the CppEngineHost.exe process next time the hang happens. If the hang is related to the Clang IntelliSense engine, this should help.

[support]

Hi,

The file is only needed to setup non-Clang IntelliSense; if you don’t get any other errors, you can simply ignore this problem (and/or remove the reference to the file via VS project properties -> NMake settings -> Forced includes).

[support]

Hi,

You don’t need to delete the VisualKernel folders/keys, only the Visual Studio ones:

• C:\Users\<user>\AppData\Roaming\Microsoft\VisualStudio\14.0
• C:\Users\<user>\AppData\Local\Microsoft\VisualStudio\14.0
• HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0
• HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0_Config

We recommend renaming the folders/keys before you confirm that it solves the problem in case you accidentally delete something critical.

[support]

Hi,

When you try to insert a breakpoint in a running program, VisualGDB sends a Ctrl-C signal to the gdb and it response gdb tries to halt your program. If anything on this path is broken, settings breakpoints in a running program won’t work.

This could be caused by your program altering the handling of SIGINT or some system-wide settings. If it only happens with one project, we would recommend placing an infinite loop in main(), checking that ‘Break all’ still works, and then moving the infinite loop around to find the code that breaks the Ctrl-C handling.

[support]

Hi,

We have double-checked the window. The GUI thread should have the following attributes set:

• Both Category and Name should read “Main Thread”
• The Managed ID should be 1

In order to get past the “external code” issue, please right-click in the Call Stack window and select “Show External Code”.

Alternatively you can simply select Debug->Save Dump As, upload the dump file (~1GB) to dropbox and share a link so that we could investigate it on our side.

[support]

Hi,

This can actually be changed via VisualGDB Project Properties (we made it into a separate setting to simplify troubleshooting). We normally mention this in our tutorials; if you followed one that does not mention this setting, please let us know and we will update it.

[support]

OK, this is starting to look like a corrupt VS installation. Please try installing VisualKernel from another user account and check if it works. If it does, please try renaming/removing per-user Visual Studio folders and registry keys so that VS can reinitialize its environment and then reinstall VisualKernel again.

[support]

Hi,

No problem. Please follow the steps below:

1. Ensure you have exactly 1 instance of Visual Studio running
2. Start another VS instance
3. Select Debug->Attach to process
4. In the process list select devenv.exe (Visual Studio) and in the “types of code to attach” select “automatic”.
5. Click “Attach”
6. Click Debug->Break All
7. Open the Debug->Windows->Threads window, locate the GUI thread and double-click on it
8. Open the Debug->Windows->Call Stack window, select all frames and copy-paste them here

[support]

Hi,

If it was not VS2017, we would recommend attaching another VS instance to the hanging one and checking the call stack of the main thread. This should explain what exactly is causing the delay.

[support]

Hi,

If you are using VS2017, this could be caused by the bugs in the AddFilter() API in Visual Studio.

We are actually experimenting with editing the .vcxproj files directly instead of using the buggy API, so feel free to try this build and let us know if it solves the problem: http://sysprogs.com/files/tmp/VisualGDB-5.3.1.1509.msi

[support]

Hi,

Not in the next 2-3 months, sorry.

[support]

Hi,

This could be caused by some strange interference with VisualGDB. Please try uninstalling VisualGDB and see if VisualKernel menus reappear. If yes, please let us know your VisualGDB and VisualKernel versions.

[support]

Hi,

We have managed to get it working, but it currently interferes with our FLASH programming logic, so using this mode is somewhat hacky:

1. First add “-Wl,–undefined=uxTopUsedPriority” to your linker command line in order to include the symbols necessary for OpenOCD to detect FreeRTOS.
2. Then start debugging and load your firmware to FLASH as usual.
3. Once the firmware is loaded, edit the <sysgcc>\esp32\esp32-bsp\OpenOCD\share\openocd\scripts\target\esp32.cfg file as follows:

   set ESP32_RTOS FreeRTOS
   ...
   #target smp $_TARGETNAME1 $_TARGETNAME2 <==== Comment this line at the end of esp32.cfg

4. Now disable FLASH programming on the Debug Settings page of VisualGDB Project Properties and run debugging.

Next time you modify your program, you would need to change the esp32.cfg back and re-program the FLASH (or use esptool.py to program the FLASH over the serial port).

[support]

Hi,

Thanks for checking this. If the extension is loaded, please check if it appears under Tools->Extensions and Updates and whether the Help->About VisualKernel command is visible. If yes, please let us know what exact functionality is broken.

[support]

Hi,

The STM32 software packages often break backward compatibility in minor ways (e.g. by introducing new configuration variables that the project needs to define). Usually this type of problem can be very easily fixed by creating a new project with the new BSP and checking where the missing entity is defined. Once you locate the definition, simply copy if to the old project and it should build again.

[Author]

Posts