Forum Replies Created
-
Posts
-
Please let us know how exactly you observe the difference in the behavior (see the 3-step description format). This should help us understand what is going on and suggest steps to fix it.
Hi,
Please try restarting your computer. If it doesn’t help, please try comparing the OpenOCD command lines used with Visual Studio Code and with VisualGDB. Ensure that you are using the same scripts and other command line arguments in both modes.
If all the options are the same, please try running the VisualGDB’s OpenOCD manually with the command line shown in the log and then try connecting the esp32 GDB to it (target remote :<port>) and let us know what happens then.
Hi,
Normally, GCC would handle the system include directories automatically, so VisualGDB does not offer any special settings for overriding this.
You could try adding the -nostdinc option to CFLAGS and then entering all include directories (system and regular) in the order you are trying to use, however we would advise against this, as such setup would be very fragile and could stop working if the internal directory structure of the toolchain changes in the next GCC version.
Hi,
This looks like something managed by the ESP8266 SDK itself and not by VisualGDB. Please consider asking on the Espressif’s forum instead.
We are aware of the -dumpversion switch, however the GNUARM toolchain location logic does not utilize it because the version does not affect anything other than the toolchain selector.
You can override the version by manually editing the toolchain.xml file (either in the toolchain folder or under %LOCALAPPDATA%\VisualGDB\ToolchainProfiles after importing the toolchain. All other files containing the toolchain version are generated based on it.
Sorry, this is a side effect of the registry-based toolchain discovery. The toolchain should work correctly, however the tool versions shown in the toolchain selector will indeed be incorrect.
As a workaround, please try importing the toolchain manually by clicking “Locate toolchain by finding the gdb executable” in the toolchain selector.
In order to solve the build issues please double-check that the bootloader project is set as a build dependency for the main project (step 19 of the tutorial). Otherwise Visual Studio will try to build both projects in parallel and will indeed not work.
To solve the entry point issue when debugging, please set the “reset after programming FLASH” checkbox in debug settings (step 23 of the same tutorial).
Hi,
Please check the built log (View->Output). It will show the output from ld.exe (GNU linker) that should contain more details about the cause of the error.
Thanks for the very detailed description and repro steps.
Unfortunately, this is a known limitation of VisualGDB. The “Nordic BSP Samples” are automatically converted from the samples included in the Nordic SDK and hence do not follow the regular embedded framework layout used by VisualGDB and would require manual adjustments after conversion to a stand-alone project.
As a workaround, please try creating a project based on the regular VisualGDB-supplied samples that are fully compatible with the stand-alone project format.
Sorry, “extract function” is not yet supported by Clang IntelliSense. It is planned for the next major VisualGDB release, however is not available yet.
The ARM simulator built into gdb is indeed very basic and does not simulate most of the modern devices like STM32. VisualGDB shows it in the debug method list for backward compatibility with older devices where CPU-only simulation would make sense. For STM32 devices we recommend using one of the ST’s development boards with ST-Link.
OK, we have updated VisualGDB to automatically remove the temporary files from the previous ESP-IDF versions when changing the toolchain or the IDF checkout.
Please try this build: VisualGDB-5.4.105.3154.msi
Sorry, we are not the vendor for SimplicityStudio. For generic SimplicityStudio questions, please contact Silabs. If you need help with one of the Sysprogs products, please let us know and we will be happy to help you.
Please double-check that your source file includes the necessary header files.
Plain C supports calling functions without declaring them first. This creates an implicit declaration based on the arguments provided, however as it is not explicitly linked to the actual function, the Clang IntelliSense won’t be able to find it.
