Forum Replies Created
-
Posts
-
Hi,
Sorry, live variables require the target to support reading memory without stopping. This is supported by ARM Cortex-M and some Cortex-A targets, but not on ESP8266 or ESP32 targets.
Hi,
VisualGDB primarily focuses on setups that support debugging, so it doesn’t offer out-of-the-box support for FLASHing the non-debuggable chips with avrdude. That said, there’s a very easy workaround for that.
The VisualGDB build process produces the regular ELF files compatible with almost all open-source tools (including avrdude), so running it manually with a VisualGDB-produced executable should work.
If you are using a Custom edition or higher, you can automate this by adding a custom project shortcut (Project->VisualGDB Custom Shortcuts). This will add a custom menu command to the Project menu and the context menu (if using VisualGDB 5.4 preview) that will run an arbitrary command line.
Hi,
Thanks for the suggestion, we will consider adding detailed allocation analyzer to one of the next VisualGDB releases.
Currently VisualGDB supports FreeRTOS thread names through an open-source plugin (requires the custom edition or higher, should fully work in trial mode). If it doesn’t work, please share a diagnostic gdb log and a screenshot of the Threads window and we will investigate.
Although VisualGDB currently won’t show dynamically allocated regions, it can highlight the bounds of global variables and stack frames in the memory window. Simply use the advanced memory window and enable global variable highlighting via the toolbar.
Hi,
Please refer to the following page for the explanation of the linker-related settings: http://visualgdb.com/support/linkerinputs/
Hi,
No problem, please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2349.msi
Hi,
No problem, this looks like our bug. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.3.2349.msi
Hi,
We have quickly checked the internals of the Go to All mechanism and it looks it depends on some undocumented interfaces implemented by the regular Visual Studio project types. We might be able to support something similar during quick debug (by exposing a virtual pseudo-project), however we won’t be able to fit this into the upcoming v5.4, sorry.
Hi,
The regular ESP32 project support (not the new advanced ESP32 IDF project wizard) is based on ESP-IDF 2.x won’t work with examples from other ESP-IDF releases. It also uses a slightly different build process than the original ESP-IDF (in order to be compatible with MSBuild), causing problems with some samples.
This is exactly the reason we designed the new Advanced ESP-IDF Project Subsystem that works on top of ESP-IDF and is fully compatible with it. Please use the new advanced project subsystem (and the corresponding wizard) instead of the regular Embedded Project Wizard.
Hi,
Yes, any FT2232-based JTAG adapter (including Olimex ARM-USB-OCD-H) should work. For the exact pin configuration, please refer to the tutorial for the board you are using.
Hi,
If you are using a custom edition, you can simply add an extra pre-build action to transfer any amount of arbitrary source directories. If you are using a lower edition, simply creating a pseudo-project to facilitate the transfer should work as well.
Another option would be to try the Advanced CMake Project Subsystem and switch your project to CMake. CMake projects can have multiple targets (executables/libraries) inside one project sharing the same file transfer settings.
Hi,
Long-term we are planning to add a tool window (similar to Solution Explorer) that will let you easily browse through files seen by the gdb (with filter). However this feature will not make it into the upcoming v5.4, sorry.
Hi,
Thanks for clarifying this. Please try clicking the “test connection” button in both cases, copy the OpenOCD command line shown in the test window and then compare the working command line with non-working one. Then please try running OpenOCD manually to determine a specific flag that causes the issue.
Hi,
In our experiments this worked differently with different JTAG debuggers (e.g. Segger J-Link vs Olimex), so we would advise trying both to see which one works with your device.
Hi,
No problem, we will try to explain how this works.
Function calls like _write() are the low-level calls used by the standard library to implement basic I/O. E.g. if you call printf(), the library itself will format the text and then will call _write() to actually send out the exact string. VisualGDB projects can have one of the following implementations of those functions:
- Regular semihosting. Selected via the first page of VisualGDB Project Properties and is slower than the advanced semihosting. The output from printf() will appear inside Visual Studio.
- Advanced semihosting. Selected by referencing the corresponding framework via VisualGDB Project Properties -> Embedded Frameworks. Similar to the regular semihosting, but only works with VisualGDB and is much faster than the regular one.
- Any other implementation that is built together with your code (i.e. a .c or .cpp file defining those functions). E.g. it may redirect printf() output to a UART port.
Most likely you have imported some implementation of those functions together with your project, causing conflicts between it and the regular semihosting. To fix this, you need to ensure that only one of the options mentioned above is enabled. One way to do this is to select “none” in VisualGDB Project Properties, another way is to remove syscalls.c from the project. If it looks like syscalls.c was just copied from the standard library and doesn’t add any functionality on top of that, we would suggest removing it to reduce the codebase size. Otherwise, disabling semihosting via VisualGDB Project Properties like you did, is the right way to go.
