Forum Replies Created
-
Posts
-
Hi,
Normally, just adding a config file should be sufficient, however there could be several factors interfering with it. Please try reopening the solution file to reset all caches; if it doesn’t help, please check whether the new configuration entries appear in the command-line configuration interface (right-click on the project in Solution Explorer -> Open MinGW shell -> make menuconfig). If not, please check with Espressif whether the ESP-IDF version you are using requires some additional steps (or try comparing your project with one of the samples that has custom KConfig files).
If the entries appear under make menuconfig, but not with VisualGDB, please let us know your esp-idf version, your project type (Make/CMake) and the exact steps to reproduce it (if the problem can be reproduced by adding a KConfig file to a basic ledblink sample, please archive and attach the project demonstrating the issue) and we should be able to fix it promptly.
As mentioned above, this looks like an incompatibility between the OpenOCD FLASH driver and the custom FLASH programming code you are using.
As both of those components are external to VisualGDB, unfortunately is it not covered by our product support. Please consider contacting ST support for further help on this.
Hi,
The easiest way to get this to would would be to manually add the source directory containing the files to VisualGDB project properties -> Extra Source Directories.
We understand that it is an extra configuration step and will update VisualGDB to do it automatically in the next major release along with other mbed-related improvements.
It looks like some specific part of your code is triggering a bug in Clang (it fails to resolve an incomplete template). The easiest way to fix this would be if you could narrow it down to a specific combination of headers and send them to us along with the repro instructions. If this is not possible, we can send you a special diagnostic build of the Clang engine that will help us pinpoint and fix the problem based on the crash dump.
It is hard to say what exactly is going on, as VisualGDB uses an external tool (OpenOCD to program the FLASH memory and manage debugging), but most likely you set some FLASH attributes (e.g. sector protection) to a state that would prevent OpenOCD from reprogramming it.
Unfortunately, we are not able to review your projects as a part of our regular product support, however we can suggest some relevant documentation:
- You can read about OpenOCD’s commands for managing FLASH memory on this page.
- You can build OpenOCD from source code and step through it as shown in this tutorial.
Please also feel free to check on the ST’s forum. The OpenOCD’s FLASH memory driver for most of the STM32 devices was contributed by ST engineers, so they might be able to explain what is going on.
Hi,
Most likely the problem is caused by some configuration change on your side and is not related to the update.
Please try narrowing down the problem to a specific sequence of steps that doesn’t work (see the 3-step reporting guidelines here) and we should be able to help you get it to work.
Hi,
This looks like a rendering issue that was introduced by a recent Windows 10/VS2019 update. Please try updating VisualGDB to the latest 5.4R11, as it includes a workaround for this.
Hi,
Yes, please ensure you are using the latest VisualGDB 5.4R11. This Ctrl-Click support was added to VisualGDB’s Clang IntelliSense fairly recently and older builds of VisualGDB don’t support it.
Good to know the installer works now.
Regarding the Arduino package numbers, indeed the default Arduino package layout would allow having multiple versions of the same package installed. This matches the behavior of the regular Arduino tools and should not cause any problems. If you would like to reclaim the disk space used by the old packages, it is safe to simply delete their folders.
Hi,
This looks like some cached data on your side is incorrect. Please try opening Tools->VisualGDB->Manage VisualGDB Packages->Online to update the package list.
No problem, we can explain what happened.
The linker automatically discards the symbols that are not referenced by any other symbols in the project, starting at the entry point. E.g. if your main file contains functions func1() and func2(), but main() only calls func1(), the body of func2() will be removed from the linked binary in order to save space. However, it the entry point itself is eliminated, every function in the project will be considered unused (unless explicitly marked with special GNU attributes or linker script directives) and hence the linking will produce a nearly empty result.
No problem, we can help you get it to work.
The “Convert to MSBuild” command will import the common parameters (e.g. include directories and macro names) from the Makefiles and copy them to the MSBuild project properties, however it would not pick up custom Makefile rules and other adjustments. This should work for most of the projects, but may indeed require minor manual adjustments to reflect the settings that were not automatically converted.
Based on what you have described, the assembly files did not get the correct item type and hence are being ignored. Please try selecting them in Solution Explorer, right-click and select Properties (for those items) and set the Item Type on the General page to C/C++ compiler. Please also ensure that they are not marked as “Excluded from build”.
If this doesn’t help, please let us know and we will provide more detailed instructions.
Sorry for the confusion. If the physical library name doesn’t include the “lib” prefix, the easiest way to add it to the project would be to simply add it to the Solution Explorer as if it was a source file (Add->Existing Item). This will have the same effect as using the “Additional linker inputs” field, but will make it slightly easier to manage.
Thanks for clarifying this. Normally, VisualGDB should automatically pick up the header and source file locations from the GPDSC file, although in our experiments the STM32CubeMX tool can intermittently omit some of them, depending on the project settings and the tool version.
Based on the behavior you described, the GPDSC file was missing multiple FreeRTOS-related components; in that case it could be easier to add reference to FreeRTOS via VisualGDB Project Properties -> Embedded Frameworks.
Please also feel free to attach the generated project (as long as you are using the latest STM32CubeMX release) so that we could recheck if we could update the VisualGDB to extract the correct FreeRTOS component paths.
