Forum Replies Created
-
Posts
-
Hi,
Most likely, you have picked an incompatible combination of the STM32 BSP, USB library and project-specific files. If you would like to manually combine components from different sources, please make sure you understand the STM32 project structure per our documentation.
Alternatively, please consider cloning one of the USB-specific STM32Cube samples via VisualGDB Project Wizard. They are automatically tested before release and should build without any errors.
You can also try using the new STM32CubeMX project wizard added in VisualGDB 5.5 RC1. It provides the best out-of-the-box integration with STM32CubeMX and automatically avoids conflicts between different components.
Thanks for confirming this. It looked like an issue that was recently fixed, so we wanted to double-check that it is not caused by using an old build. We also moved this into a separate forum thread, as the issue appears different from the one discussed in the original thread.
Either way, this looks like the connection between VisualGDB and the floating license server gets lost, and the floating license state is not updated properly. If you could create a ticket for this via our support form, we can send you a private link to a special diagnostic build that should help narrow it down. Please do let us know what version of Visual Studio you are using so that we can double-check it on our side first.
Thanks for the log. Just to double-check, could you please confirm the build number from the Help->About VisualGDB window?
No problem, we have published detailed documentation on the Memory Explorer window here: https://visualgdb.com/documentation/embedded/memoryexplorer/. It also explains where VisualGDB takes the list of symbols, memories, and how stack/heap are typically placed.
Note that the nRF5x linker scripts (that control the stack/heap placement) come directly from the Nordic SDK, so please refer to its documentation for details specific to Nordic devices.
No problem. Please try enabling diagnostic logging via View->Other Windows->VisualGDB Diagnostics Console. Then please try reproducing the problem and attach the full log from the diagnostics console here.
No problem. Indeed, unlike other SDK generators, the Atmel START generator exports the entire project as a single atomic component, so VisualGDB follows its structure and does not allow the selection of individual sub-components.
That said, you can mark individual files from the Atmel START SDK with the “excluded from build” flag and then copy them to the project directory and include them into the project manually. This will allow referencing the existing SDK, while keeping project-specific customizations.
Hi,
In order to use semihosting or serial output, it needs to be properly supported by the debugged program. I.e. the call to _write() should be routed to the code that outputs the data to either semihosting interface, or the serial port.
The semihosting-specific implementation of _write() is usually provided by the toolchain and can be used for regular embedded projects, however as Arduino uses its own build system, it won’t work there out-of-the-box. Our best advice would be to first get semihosting working on a regular embedded project for the same target, understand the involved compiler options (e.g. by comparing the .rsp files) and then try patching the Arduino build scripts to replicate them. That said, this will require non-trivial troubleshooting and may not work at all.
It could also be worthwhile to check whether the Arduino core for your device provides an existing setting that would enable this functionality.
Thanks, this makes sense. If the frequency is configured conditionally based on the DEBUG macro, it will indeed show different results in Debug and Release builds.
@whinis, thanks for sharing this. The changes look good, however they would limit the scope of the importer to a handful of preselected devices, and may reduce compatibility with future updates on the Atmel START side, so we would currently keep the existing more generic implementation.
That said, please consider trying the new Embedded CMake Project Subsystem (available in VisualGDB 5.5 RC1). It supports converting individual frameworks into stand-alone frameworks (i.e. included with the project), and also provides convenient GUI for reassembling a stand-alone BSP and a number of stand-alone frameworks back into a shared BSP. This should simplify the handling of complex setups a shared core and a set of minor per-project customizations.
This is something to check with your build server documentation. From the VisualGDB side, as long as it’s launched with the correct environment, it will expand the variables as expected. You can try experimenting with .bat files, however as this is generally something outside VisualGDB’s control, the help we can provide with it is somewhat limited.
Hi,
Unfortunately, MSBuild doesn’t automatically pass custom properties to tasks (you can do it explicitly by patching the .targets files, but it’s generally not recommended). The easiest workaround would be to pass the setting via an environment variable. VisualGDB expands the environment variables together with the internal variables, such as $(ProjectDir).
In order to avoid additional clarification steps and get relevant help faster, please consider following our problem reporting guidelines. As your initial report compared debugging a debug configuration vs. running a release one, we assumed that the problem is caused by using a debugger. If running the debug build without debugging doesn’t work either (and release one works), most likely the lower optimization level of the debug build causes some kind of error (e.g. a stack overflow, memory corruption, or a timing bug). Please consider manually overriding the optimization level of the Debug configuration to match the Release configuration. If it helps, you can try changing optimization level for individual files, until you can find a specific file triggering the problem.
The Keil compiler is very different from GCC, so it is completely expected that switching a large project between the compilers would require some additional troubleshooting. If you prefer, you can configure VisualGDB to use the Keil compiler as well: https://visualgdb.com/tutorials/arm/keil/
Thanks for renewing your license. Regarding the frequency, most likely the program triggers several breakpoints before the USB requests get properly handled.
Please try removing all the breakpoints and make sure the device responds to the USB requests. If it still doesn’t work, please try programming the FLASH memory without debugging, restart the device, make sure it is recognized, and then try attaching to it as shown here: https://visualgdb.com/tutorials/arm/attach/
If attaching a debugger breaks further USB functionality, please try connecting to the device using the native debugger tool (e.g. ST-Link tool or J-Link Commander) instead. If this also breaks the USB functionality, most likely the board has insufficient power, or has some wiring issues.
No problem, we do not mind sharing the instructions. We simply prioritize requests for documentation based on the amount of affected users (we have recently published a lot of new documentation on common topics). As you have seconded the topic, we are happy to provide more details.
Once you import an Atmel START SDK into VisualGDB, it creates a BSP.XML file in the SDK directory that contains the information extracted from the SDK. Then, the BSP is registered with VisualGDB by creating a %LOCALAPPDATA%\VisualGDB\EmbeddedBSPs\arm-eabi\<id>.bsplink file pointing to the SDK directory.
The easiest way to support multiple imported SDKs would be to manually edit the BSP.XML file, changing the following elements:
- BoardSupportPackage/PackageID – change to unique names in order to avoid collision between multiple versions
- BoardSupportPackage/PackageDescription – set to any arbitrary string to help you distinguish the packages
- BoardSupportPackage/SupportedMCUs/MCU/UserFriendlyName – add an arbitrary suffix, such as ” (Basic)” or ” (Full)”. The suffix will be shown in VisualGDB GUI when selecting the device in the device list and won’t affect anything else.
Once you have changed the file, reopen the Tools->VisualGDB->Manage VisualGDB Packages window to trigger a reload of all packages. After that, you will be able to import another Atmel START SDK from another directory, and VisualGDB will keep both instances, since they will have different package IDs.
If the build always works, but the clean always fails, most likely some clean-specific setting (e.g. a custom post-clean step or a custom clean command) refers to an invalid hostname.
If you are not sure what causes it and cannot easily revert to a previous version of the project that worked successfully, please consider doing a side-by-side comparison of the broken project against a similar working project. I.e. compare the .vcxproj and .vgdbsettings files and try merging them until you can pinpoint a specific setting that triggers it.
