[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.

[support]

No problem, we ran a quick test with OpenOCD. It turns out that when OpenOCD accepts an incoming connection from gdb, it tries to detect the FLASH ID of the on-board FLASH memory and the code used to do that hangs, so on OpenOCD side it looks like a gdb timeout and on gdb side it looks like an OpenOCD timeout.

Looks like there were attempts to add support for LPC1549 into OpenOCD (e.g. see this patch), but they seem to be abandoned, most likely due to low interest. As the J-Link solution works out-of-the-box and does not require any extra hardware (the on-board LPC-Link can is turned into a J-Link), we would recommend using it instead and will not do any more investigation into the OpenOCD bug. Let us know if you would like us the send you the board back.

[support]

Hi,

Thanks, that’s a good point. We will consider adding some sort of an “under investigation” flag to the forum posts so that we can share the investigation progress without closing the topics.

[support]

Hi,

Please try running devenv.exe /ResetSkipPkgs. If this does not help, please double-check that the “C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Sysprogs\VisualKernel\extension.vsixmanifest” file exists and is not corrupt. If this does not help either, please try running devenv.exe /log and check the ActivityLog.xml file for messages related to VisualKernel.

[Author]

Posts