Forum Replies Created
-
Posts
-
Hi,
Please refer to the following page for a detailed explanation of ESP-ADF vs. ESP-IDF versioning: https://visualgdb.com/documentation/espidf/#espadf
Hi,
Sure, you can either uninstall VisualGDB and install it back, or use the “Modify” button in the regular Add/Remove Programs window.
Thanks for letting us know and good to know it works. If the device vendor provides a usable toolchain, indeed, you can easily import it into VisualGDB and don’t need to build it yourself.
Hi,
Normally, VisualGDB checks for missing packages when loading the project, and displays a window suggesting automatically installing the missing ones. Most likely, something else in your setup interfered with this mechanism.
If you could confirm that a specific sequence of actions that can be reproduced from scratch, triggers the issue, we can gladly investigate it further (e.g. Create a project using the ARM toolchain -> Remove the toolchain via VisualGDB Package Manager -> Restart VS -> Open the project).
Hi,
Indeed, neither Visual Studio nor VisualGDB supports syntax highlighting in the assembly files. That said, it does not affect debugging. When you set a breakpoint in a source file, VisualGDB simply issues a -break-insert command directly to the gdb debugger, that in turn interprets the debug symbols and translates it to a physical breakpoint at a specific address. The process of translating source file locations to memory addresses is entirely done by gdb and is not affected by any IDE features. You can double-check the commands issued by VisualGDB to gdb via the GDB Session window.
If the breakpoints are not working, the assembly files could have been built without debug symbols, or some macros inside them might be interfering with the way gdb handles breakpoints.
You can also try using the Disassembly view in Visual Studio. It takes the assembly dump directly from gdb and knows the exact address of every line displayed there. Hence, breakpoints set via the Disassembly view will work regardless of the symbol issues.
Sorry for the delay. We have finally managed to reproduce the issue and it turns out it was caused by a race condition in the hardware register window initialization logic.
We have fixed it in the following build: VisualGDB-5.6.104.4554.msi
Hi,
No problem, we can gladly build a toolchain for you. Feel free to contact our sales with the details about your target and we will give you a quote.
Hi,
This looks like an issue between the module and the Espressif’s port of OpenOCD, and hence is not directly controlled by VisualGDB. Please consider contacting Espressif for further help with this issue.
You can also try reproducing it by manually running the OpenOCD build from the Espressif github repository. It it works better, we can help you configure VisualGDB to replicate the correct behavior.
Update: we got another report of a similar issue in this thread, and the workaround suggested on the Espressif forums is to pass the “esp appimage_offset 0x20000” command to OpenOCD. With VisualGDB, this can be done by adding the following text to the end of OpenOCD command line in VisualGDB Project Properties -> Debug Settings -> Advanced:
-c "esp appimage_offset 0x20000"
Hi,
In order to build the Linux applications on Windows, the cross-toolchain needs to be built specifically for that target using precisely the same settings as the original gcc. I.e. it needs to use the same ABI settings, same versions of libraries, same distro-specific gcc patches, and so on. Synchronizing sysroot on a similar toolchain would lead to unpredictable consequences: it might work, or it could trigger strange compile-time or runtime issues. You can read more about it here: https://visualgdb.com/documentation/linux/boards/.
If you are using a custom Linux board, the board vendor might already provide a toolchain, or scripts for building one. We could also build one for you for a small fee. Feel free to reach out to our sales to get a quote.
It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey
Hi,
Please refer to your Linux distro documentation for instructions on installing gdbserver and other tools.
Good to know it works. That said, Visual Studio should normally set the PATH automatically, so the problem could have been solved by simply restarting VS.
No problem and good to know it works. If you encounter further issues, feel free to create another thread.
Thanks for the screenshot. This build should work just fine. Please try running the build from command line:
msbuild.exe <.sln file> /p:Platform=VisualGDB /p:Configuration=Debug
If it also hangs, please try obtaining a stack trace of the msbuild.exe process as shown here.
If the manual build works, but the build from VS does not, please try closing ALL VS instances, starting just one, and doing the build again. Once it hangs, please try checking the call stacks of all MSBuild.exe processes (VS would normally launch multiple ones) and searching for the ones having VisualGDB methods on the stack.
Hi,
In order to select the exact set of tests to run, VisualGDB sets a breakpoint in the SysprogsTestHook_SelectTests() function and reads/writes the variables pointing to the test that are about to run. Most likely, the optimizer is somehow interfering with this variable in your case.
We would advise enabling the GDB logging via VisualGDB Project Properties, checking the exact gdb commands sent by VisualGDB when the breakpoint in SysprogsTestHook_SelectTests() triggers and double-checking that they succeed (i.e. the actual memory gets modified). If not, you may need to disable optimization for the corresponding source file, or reorganize the code (e.g. promote some local variables to global ones to prevent the optimizer from removing them).
