[support]

Thanks, this indeed looks like VisualGDB doesn’t apply the test framework path properly. We have tried reproducing it on a newly created project, but could not get this behavior. It might be caused by some settings of this specific project. Please try checking if the problem persists on a newly created project. If not, please make a backup of the project, open VisualGDB Project Properties on the Test Framework page and change the framework back and forth. If this solves the problem, we would appreciate it if you could share the differences between the old and new project files so that we could fix it.

[support]

You could try enabling the preprocessor output (via VS Project Settings -> C/C++ if you are using MSBuild) to track this down (it will expand all preprocessor macros and include directives and save the output to a .E file), however disabling/ignoring this warning should be completely OK unless you are planning to port your code to ARM64.

[support]

Please try enabling the option in the “Find” window and then restart Visual Studio. Next time you start it, “nostop” will be automatically added to all entries in the target list.

You can disable the CodeJumps references by clicking at the tag button in the top right corner of the screen.

[support]

It is. If anyone else is willing to provide help with this, they are absolutely welcome to do that. We just wanted to clarify that we won’t be able to provide any support from our side unless you renew your license.

[support]

Hi,

Looks like your support period has expired. In order to receive technical support, please renew your license here: https://sysprogs.com/splm/mykey

[support]

VisualGDB would query the include search path by running gcc from the toolchain and letting it dump the specs (macros and include paths), so it’s usually very accurate.

Please try clicking on “int32_t” and select “Go to definition”. Does the file/location shown there make sense?

[support]

No problem. _sbrk() is usually implemented by the standard library (you can select the syscall implementation type on the first page of VisualGDB Project Properties). If you want to fine-tune the location of the heap, you can add your own implementation of this function (see this tutorial).

[support]

Hi,

Please try updating to the final v5.4 release. The beta version contained a bug that would cause this type of problem.

[support]

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.

Attachments:

You must be logged in to view attached files.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[support]

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.

[Author]

Posts