Forum Replies Created
-
Posts
-
Hi,
The “undefined reference” error means that a certain function has been declared, but not defined (see this tutorial for a detailed explanation). With FreeRTOS, it would happen if the heap_<N>.c file (that implements the heap functions) was not included in the project.
First of all, please try creating a FreeRTOS-based project via the regular Embedded Project Wizard, then locate the heap file in Solution Explorer, and take a note of its location under the FreeRTOS directory (you can change the heap type via VisualGDB Project Properties -> Embedded Frameworks -> Configuration).
Then, please check the .gpdsc file generated by STM32CubeMX for a reference to a similar file (heap_<N>.c). If the file is referenced, it’s a bug in our STM32CubeMX importer and we should be able to fix it if you could attach the .gpdsc and .ioc files. If the file is not referenced, it’s a bug in the STM32CubeMX generator, and you can work around it by manually adding the heap file to the project via Add->Existing Item (the menu option will not appear under the STM32CubeMX Project node in Solution Explorer, as this node’s contents are managed by STM32CubeMX).
Please try checking if the build output window contains any error messages. If the build fails due to errors, please resolve them and make sure the build succeeds before proceeding with debugging.
If you cannot find any error messages, please share a screenshot of the VisualGDB Build window and the regular Output window after building the project (not trying to launch it).
Hi,
Looks like you are trying to launch a project that has not been built. Please try building it first.
Hi,
Please make sure you use the new STM32CubeMX Project Wizard as shown in this tutorial. It will setup the necessary files automatically. If it still doesn’t work, please attach the screenshots of all the wizard steps in your setup, as well as any error messages, and we will help you understand what is going on.
Hi,
The FreeRTOS package included in the STM32 BSP is taken from the latest STM32F7 SDK at the moment of the BSP generation. Hence, once ST updates the STM32F7 SDK to include FreeRTOS 10.4.1, our BSP will include it as well.
That said, you can always fork our STM32 BSP generator and tweak it to use any versions of SDKs and frameworks of your choice.
Hi,
VisualGDB would normally just use the “load” command to program the FLASH memory and would not issue any locking commands. You can find out the exact commands used by VisualGDB by creating a gdb log file. You can try passing additional commands to the gdb stub (using the “monitor <command>” syntax) by expanding the “Advanced Settings” view under VisualGDB Project Properties -> Debug Settings. See the J-Link documentation for a list of monitor commands related to memory protection.
If nothing helps, please consider checking with Segger support. They might be able to suggest a command for controlling the FLASH memory erasing.
Hi,
This is to be expected. The STM32CubeMX tool generates Plain C files, so placing C++ code in them will result in errors. You can still add .cpp files to the STM32CubeMX-generated projects as shown in our STM32CubeMX tutorial, however it will require carefully partitioning the code into Plain C and C++ parts, and declaring the functions that need to be visible from both parts with extern “C”.
As an alternative, please consider using the regular VisualGDB Embedded Project Wizard that can generate a C++ main file instead.
Please note that we prioritize the reported issues based on the amount of affected users. As this issue does not affect other users, we will not be able to provide any further help with it. If you are not able to continue your VisualGDB trial due to it, please consider using other tools as we will not be able to address it at this point.
Thanks for your feedback. We have added it to our internal issue tracker and will investigate it further if the issue is confirmed by other users.
Hi,
These files should normally be a part of the toolchain and should be located automatically. If they don’t work, most likely either toolchain, or the project is corrupt.
Please try reinstalling the toolchain via Tools->VisualGDB->Manage VisualGDB Packages. If it doesn’t help, please try reproducing the problem on a project created from scratch.
Thanks for confirming your support status. You can turn off unsupported encoding hints using the “Show Unsupported Encoding Hints” setting under Tools->Options->VisualGDB, as long as you are using the latest VisualGDB 5.5R2. See this page for the exact and up-to-date path of the setting.
No problem, we will clarify. VisualGDB supports many different project types. Some of them (like MSBuild or Advanced CMake) are recommended for new setups, while others (like Makefile-based) are considered legacy and are only recommended if you need backward compatibility with older VisualGDB versions, or projects that were created earlier.
No problem. This looks like a legacy VisualGDB project type that is internally implemented as a NMake-based VC++ project. You can try narrowing down the problem by creating a regular VC++ Makefile project via the VC++ project wizard and setting a dummy build command (e.g. “cmd /c echo done“). If it breaks the same way, please try checking with Visual Studio support.
If the VisualGDB-based project behaves differently from the regular NMake project, please try comparing and merging the .vcxproj files. Some element (e.g. PlatformToolset) could be set differently in these 2 projects and could be causing this behavior.
Also, for most of the new project setups we recommend using Advanced CMake projects. They do not require the VC++ project subsystem and often work more reliably.
