Forum Replies Created
-
Posts
-
Thanks for the project file. We have rechecked the import and the macros got imported properly. If you believe some specific macro is not being imported, please let us know and attach the relevant screenshots.
Thanks for clarifying this. Most likely your project has inherited the header files from the time it was a regular non-standalone project. For stand-alone projects you can use the first page of VisualGDB Project Properties to review and remove the source/header files that are considered part of the BSP and will be re-added to the project.
Hi,
Please try doing a full project rebuild (Build->Rebuild All). If this doesn’t help, please try creating a new project and if it doesn’t built, reinstall the toolchain.
If nothing helps, you can install the previous ESP-IDF (v3.1) via VisualGDB Project Properties -> ESP-IDF Settings. Simply use the “install” button on the ESP-IDF version selection control.
The behavior changed because v5.3 relied on Visual Studio to ask for the path for the missing files. However a recent VS2017 update changed this to just displaying an error message. As a result, stopping the debugger in a system library that didn’t have sources available resulted in a confusing and annoying error message. Hence we updated VisualGDB to silently ignore the source paths that could not be resolved instead of reporting them “as is”. This eliminated the annoying message during regular debugging scenarios, but broke the rare scenario when the sources are not physically present on the Linux machine and not covered by the path mapping rules, but are still available and can be located manually.
We will consider adding a VisualGDB-level dialog for locating the missing sources and creating a path mapping automatically in one of the next releases. As a workaround, please add a path mapping, or use the global setting to revert to the old behavior.
Thanks for the clarification. Indeed, in this case the sources won’t be auto-downloaded as they won’t be present on the gdb machine.
As a better alternative to disabling the new behavior, please consider adding a path mapping rule via the path mappings button in the GDB Session window to link the source path reported by gdb with the actual location of the source files on the Windows machine.
Thanks for the log file. Normally, VisualGDB should have automatically downloaded the remote file to a temporary folder if it could not map the path using the regular rules.
We have added more internal logging to this logic in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2736.msi
Please try reproducing the problem and share the updated diagnostic log.
Thanks, we have rechecked this and indeed it looks like our sample project wrappers don’t include this file. We will run a few internal tests with this and will try to automatically include this file in the next releases of our STM32 package.
Thanks for the clarification. How do you import those examples into VisualGDB? Are you using the New Project -> Samples -> Use STM32CubeMX Examples setting, or a different mechanism?
Hi,
The examples like “Audio Record and Playback” come directly from ST, so we are usually not able to provide much insights into them (you might be able to get some hints from ST via their support forums) . That said, if it looks like VisualGDB is not automatically importing a file that is a part of the example, please let us know the exact example name and the device name and we will double-check this.
Thanks for confirming this. The issue might be caused by a recent change in the VisualGDB’s behavior when it cannot compute the full path to a source file on the windows side.
In version 5.3, VisualGDB would report the original path as shown by gdb and Visual Studio would show a prompt allowing you to locate the file manually. In one of the recent VS2017 updates, Microsoft changed their logic to display an error message instead, so we updated VisualGDB to simply ignore the frames referencing non-existing files.
Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2733.msi
It will show the details about the frames with missing source files via View->Other Windows->VisualGDB Diagnostics Console. If you could share the output from the diagnostics console, we should be able to see what is going on and fix it.
You can also disable the new behavior via Tools->Options->VisualGDB->Common->Debug->Hide Missing Source Files.
No problem. The option is located under Embedded Frameworks -> Framework Configuration -> Profiler -> When running without debugger.
If you don’t see this setting, please update to VisualGDB 5.4 Beta 2 and install the latest version of the profiler framework via the VisualGDB Package Manager.
Hi,
Sorry, this isn’t supported fully automatically, however there are a few workarounds.
First of all, you can configure the profiler framework (via the Embedded Frameworks page of VisualGDB Project Properties) to ignore semihosting calls when the debugger is physically not connected.
Second of all, please consider selecting the framework source files in Solution Explorer and setting the “excluded from build” flag (don’t confuse it with “Exclude from project” command). This will effectively exclude the semihosting-related logic from the release build.
Just a separate UART port won’t be sufficient for live variables. Some logic on the BMP side would need to handle the “read memory at address XXX” commands via this port, do the actual reading via JTAG/SWD and return the result.
Alternatively, we can add an API similar to the custom real-time watch that will let your program report arbitrary values via a connection such as a COM port, so VisualGDB will plot them.
Hi,
There is no VisualGDB-specific command for this, however you might be able to use the mon flash erase_address command via the GDB Session window if the Espressif’s port of OpenOCD supports it properly (we haven’t tested it yet, sorry).
