[support]

Hi,

No problem. Feel free to follow us on Twitter to stay updated.

[support]

Hi,

Thanks for clarifying this. For Make-based projects VisualGDB uses a very basic logic to track references – it will read the target name from the referenced Makefile, and will combine it with the $(BINARYDIR) expression, assuming that the binary directories for both Makefiles are the same. The resulting path will be hardcoded in the EXTERNAL_LIBS variable of the referencing project.

If you prefer using Makefiles to MSBuild, please ensure all projects that reference each other have matching binary subdirectories. Another option would be to switch to MSBuild – in this case the project references are stored as actual MSBuild references and VisualGDB will compute the correct paths during build.

Yet another option would be to try Advanced CMake (VisualGDB can import CMake-based embedded projects, but cannot create them yet). This will let you build your projects outside VisualGDB, but will also provide much better flexibility than MSBuild.

 

[support]

Hi,

The debug part of the Linux kernel is relatively buggy – unless you are using JTAG or the VMWare debug stub that runs outside the kernel, the debugging functionality will run inside the kernel and may eventually lock up when the debugger-related logic tries to access some kernel resources that are used by some other part. VisualKernel does its best working around known instances of this, however there are still many cases when debugging is not reliable.

For best debugging experience we recommend using the VMware GDB stub that runs outside the kernel.

[support]

Hi,

Thanks for the logs. We encountered the issue during our internal testing, although it happened once every 10-20 debug sessions and did not interfere with debugging (VisualKernel used the slower symbol-based module listing mechanism and it worked without any noticeable side effects).

This could be caused by some race conditions during OpenOCD initialization. We can help you pinpoint and work around this, although we may need a few iterations with this, as we cannot reproduce the behavior you are observing on our side. Please try adding the “mon sleep 3000” command under VisualKernel Project Properties -> Debug Settings -> Kernel Connection -> Advanced Settings (before and/or after the target remote command). If this resolves the problem, please try experiment with reducing the delay.

If it doesn’t help, please try stopping the debug session via Debug->Break All and try reading the block that VisualKernel tried reading during initialization (e.g. x/16xb 0xbf05f940) manually by repeating the command shown in the GDB Session window. Does this produce a valid (non-zero) result after you stop the session manually?

[support]

Hi,

This could indicate a corrupt test framework cache. Please try deleting the %LOCALAPPDATA%\VisualGDB\TestFrameworks folder.

If this doesn’t help, please open the View->Other Windows->VisualGDB Diagnostics Console and try reproducing the problem again, then post the diagnostic output. This should help us pinpoint this.

[support]

Hi,

This looks like a known limitation of the address sanitizer logic caused by heap fragmentation. Please try following the advice from this thread, although your program might be simply too large for the address sanitizer to work correctly.

[support]

Hi,

This could happen if your code contained some definitions that would not be correctly parsed by Clang (normally it would result in errors in the Error pane). Feel free to attach a repro project and we will look into fixing this.

[support]

Hi,

This does look like a valid MSBuild-based project, so it should normally work (the problems you described are very similar to what happens when trying to generate a regular Makefile-based project). Please double-check that you are using the latest VisualGDB 5.3R8.

Either way, we can help you get this to work if you could let us know how you created the project, or you could simply wait 1-2 weeks for a preview build with the new ESP-IDF advanced project subsystem that will eliminate the need to use the BSP infrastructure that constantly gets out-of-sync with the rapidly changing ESP-IDF.

 

[support]

Hi,

This looks like VisualKernel fails to use the fast mechanism to query the module list. It could happen if the JTAG connection was unreliable and the memory reads were not succeeding. Could you please try attaching the full GDB log (in the “All GDB Interaction” mode) and the full output from OpenOCD? It may contain important clues.

Another thing to try would be to lower the JTAG frequency (try as low as 500 KHz first). If this solves the problem, the JTAG wiring might be at blame and double-checking/re-soldering it should solve the problem.

[support]

Hi,

Thank you for your feedback. We are committed to making VisualGDB better than other options and are constantly working on improving the usability and adding more features. However in order to keep focusing on making our products better, we are not able to provide any free project-specific customization work, although we are happy to show examples of various VisualGDB settings and explain how they work.

If you ever decide to give VisualGDB another try, feel free to get back to us and we will be happy to answer your questions.

[support]

Hi,

Sure, we can do it as a part of our short-term consulting program. Please feel free to contact our sales to get a quote.

[support]

Hi,

Thanks, we’ll try to add an option for that to v5.4.

[support]

Hi,

This looks like you are using GNU Make; please try creating an MSBuild-based project instead – it should have all arguments escaped properly. We are also working on an experimental ESP-IDF-based project subsystem that will eliminate the need to use a separate BSP and will be able to display the ESP-IDF project structure directly in Solution Explorer. Once we release a preview build with this feature (1-2 weeks from now), we will recommend using it as the primary way of building ESP32 projects.

Regarding esptool.py, VisualGDB can do this automatically if you select “UART (program only)” in the debug method. VisualGDB can’t debug ESP32 devices over UART yet, however it will automatically invoke esptool.py to program your firmware.

[support]

Hi,

Thanks for confirming this. Just another quick question – are the flags from CMAKE_CXX_COMPILER_ARG1 mentioned anywhere else in the JSON file? If not, could you please share a repro project so that we could investigate this and submit a patch to CMake?

[support]

Hi,

No problem, the topic will remain open and if any other user would like to volunteer and look into this, we obviously won’t stop them. We just wanted to post a quick update that we won’t be able to investigate this under our usual support terms unless you extend your support period. Sorry if we caused any confusion.

[Author]

Posts