Forum Replies Created
-
Posts
-
Hi,
Normally, the function would be defined in the InstrumentingProfiler.cpp file. Please try locating it in Solution Explorer to see why the function is not properly built.
If you have enable the “use custom performance counter” setting, you would need to provide your own implementation of the function (see this tutorial for details).
Hi,
It looks like your support period has expired a while ago. Please kindly renew it here and we will be happy to point out the relevant settings.
Thanks, restarting the target between synchronizations indeed reproduced the problem. We have fixed it in the following build: VisualGDB-5.5.7.3704.msi
Thanks for renewing your license.
We have updated our CC3220 BSP based on the latest SDK from TI (v4.20.00.07). You can install it via Tools->VisualGDB->Manage VisualGDB Packages. Please also ensure you use the latest VisualGDB 5.5 Preview 7.
We have retested it with CC3220 Launchpad using the latest OpenOCD (0.10.0 2020-07-01) and it did work as expected, aside from the “most device registers are zero” error that can be safely ignored for CC3220. If it doesn’t work on your side, please share a screenshot of the error you get and we will help you resolve it.
No problem, we can help you.
This error happens when you build a FreeRTOS-based project without referencing the semihosting/profiler framework, or without defining that USE_FREERTOS macro.
If the framework is referenced and the macro is defined, please double-check that the ProfilerFreeRTOSHooks.h file is added to the project as a forced include (referencing the profiler framework should do it manually).
Hi,
Please try double-checking the exact breakpoints set by gdb by running “info breakpoints”. You might have set additional breakpoints that are not shown in the regular Visual Studio GUI.
Also please note that stepping over/out of functions requires creating a temporary breakpoint, that counts toward the overall limit.
You can also obtain a full gdb log of the debug session as shown here and search for breakpoint-related command to understand what contributes to the breakpoint amount the most.
Please also consider using Segger J-Link instead of your current debug probe, since it supports seamless software breakpoints in the FLASH memory.
Hi,
Please refer to the following pages for information on troubleshooting VisualGDB installation and loading:
- https://visualgdb.com/documentation/troubleshooting/install/
- https://visualgdb.com/support/loadfail/
Hi,
Please let us know the email associated with your license key so that we could check your support status.
Hi,
The CC3220 devices have a considerably smaller user based compared to mainstream device families, such as STM32, hence we indeed don’t update the CC3220 BSP as often.
We should be able to update our CC3220 BSP based on the latest SDK from TI (and also help you resolve any OpenOCD issues you get), however we would kindly ask you to renew your license first.
Hi,
Looks like the Jenkins machine is missing VisualGDB toolchain definitions. This is very similar to the issue discussed in this thread, so the workarounds described there should work.
If not, please let us know more details and we will help.
Please note that we usually respond to most inquiries within 24-48 hours.
Please note that VisualGDB uses the original GCC toolchain (i.e. the GNU linker) to link the projects. You can find the linker command line used by VisualGDB per our troubleshooting instructions. VisualGDB itself does not introduce any additional logic on top of what is done by the GNU linker.
Generally, we are not able to provide insights into the inner workings of the open-source tools used by VisualGDB, as they often involve very complex logic. Please consider community-driven resources like StackOverflow to get help with open-source tools.
If you are looking for a fully supported compiler, please consider using VisualGDB with IAR or Keil. This way you can still enjoy the VisualGDB features, and get compiler-specific support from IAR/Keil teams.
No problem, we will explain what is going on.
In order to avoid hardcoding toolchain parameters (e.g. the exact path) in the project files, VisualGDB maintains a per-user registry of installed toolchains under %LOCALAPPDATA%\VisualGDB\ToolchainProfiles. This registry is updated each time VisualGDB is loaded in Visual Studio (e.g. when opening a project) and is explicitly rebuilt when you run the Tools->VisualGDB->Manage VisualGDB Packages command. You can find a detailed documentation on the toolchain registry here: https://visualgdb.com/documentation/toolchains/#troubleshooting.
The “missing toolchain profile” error happens when you try to build a project that references a toolchain that is not present in the toolchain registry. Most likely, your CI setup is using a different user account (and hence a different %LOCALAPPDATA%, so VisualGDB never gets a chance to update the toolchain registry in that environment).
You can work around it via one of the following ways:
- Manually copy the relevant parts of the toolchain registry to the %LOCALAPPDATA% of the CI user account.
- Since VisualGDB’s MSBuild subsystem builds remote projects by generating a temporary Makefile (or a ninja file), you can locate it on the development machine, check it into source control, and configure your CI environment to build it instead. This way you won’t need to install neither VisualGDB, nor Visual Studio on the CI machine, however you would lose the ability to run VisualGDB-level custom actions.
Let us know if you have any further questions and we will be happy to help.
Please try installing VisualGDB 5.5 Preview 7 from our download page instead. It should include the latest updates.
It the problem persists, please let us know and we will investigate it further.
No problem, please try this build: VisualGDB-5.5.7.3703.msi
