Forum Replies Created
-
Posts
-
Hi,
The “flash bank name ‘stm32f4x.flash’ already exists” error means that the FLASH name you specify is already used by the default FLASH memory bank. Simply change $_FLASHNAME to any arbitrary name (e.g. qspi). The bank name does not refer to a specific driver, instead it defines a unique name for the newly created bank.
The “Failed to connect to the debug stub” message means that GDB could not connect to OpenOCD (most likely because OpenOCD exited with an error). Please examine the OpenOCD window (or the GDBServer log in the VisualGDB error detail window) for details.
Hi,
Most likely the FreeRTOS port file you are using is not compatible with your CPU core and floating point mode. Please try changing FreeRTOS port via VisualGDB Project Properties -> Embedded Frameworks (or manually selecting a port.c file from a different folder if you are not referencing FreeRTOS via VisualGDB framework mechanism).
Hi,
If you already have a Makefile for the GCC compiler, you can simply select “import a project built with command line tools” in the VisualGDB project wizard and it will create a wrapper project that will invoke GNU Make to build it. It won’t have a 2-way synchronization between the settings in the Makefile (e.g. list of source files) and the Visual Studio project, but would be extremely easy start with.
Another approach would be to extract the list of source files and the build settings (like header search paths) from the Makefile and manually enter it into a VisualGDB project (we recommend using creatinga new MSBuild-based project for your device to begin with). This requires a bit extra effort, but would get a 100% integrated development experience (e.g. adding a new preprocessor macro or changing optimization level would immediately take effect for both IntelliSense and build).
If you encounter any problems along the way, feel free to post the details here and we will help.
Hi,
The mechanism used in the tutorial would work for any compiler that produces ELF files that can be debugged by gdb (ARM Clang V6 is compatible). However the specific steps (e.g. the exact compiler arguments or the linking order) could be different.
We currently don’t have an out-of-the-box tutorial for the ARM Clang compiler, so we would advise trying to follow the regular Keil tutorial and making the necessary changes to account for the different compiler. If you encounter any difficulties along the way, feel free to post the details here and we will help you resolve any issues you encounter.
Hi,
This looks like a corrupt VisualGDB installation. Please try uninstalling it and reinstalling it back.
Hi,
Most likely your board is not compatible with the original Nordic boards and requires some adjustments to the code (e.g. changing clock parameters or GPIO numbers for other functions). If you are not sure, we would advise getting one of the supported Nordic boards, getting the code to work there and then moving over to the custom board.
Hi,
We looked into the new CC3220S SDK and unfortunately its internal structure is completely different from the SDK we used for CC3200.
Given that currently the popularity of CC3220S is a fraction of the CC3200 popularity, we do not have any short-term plans for fully wrapping the new SDK.
We could help you resolve any issues you discover while following the legacy device tutorial or we could also build an updated BSP for a small fee as a part of our consulting services if you don’t want to wait until CC3220S gets enough popularity for us to support it officially.
Another option would be to create a project with Code Composer and import it into VisualGDB (or debug the ELF file produced by it via Quick Debug).
Hi,
Sorry, this is a bit too specific and non-trivial to add. We would recommend using name filtering (typing a part of the method or a class) and type filters (buttons in the suggestion window) instead.
Hi,
This is a separate issue. Generally ESP32 IDF does not work when built with the disabled optimization (-O0) and requires changing the optimization level to at least -Og. This also fixes the inline functions.
Hi,
You can increase the delay via Tools->Options->VisualGDB->General->SSH->Minimal delay between PTY requests.
Alternatively please try updating your SSH package on the Linux side (see this thread for the related package versions).
Hi,
VisualGDB currently only supports kernel event tracing for FreeRTOS: https://visualgdb.com/tutorials/profiler/realtime/freertos/
We are planning to support other OSes in the next releases, although we would not name specific deadlines currently. The only workaround until we support it officially would be to look into our FreeRTOS tracing implementation that is automatically added to the projects when the tracing is enabled (it provides hooks for FreeRTOS functions and sends structured events to VisualGDB using our semihosting API) and making a quick-and-dirty equivalent of this for your configuration.
Hi,
As a quick test, could you confirm that the same problem exists with v5.3 Preview 4? If yes, please try creating a “hello, world” project demonstrating the issue and attach it here (or send it to us via the support form). We should be able to investigate this and suggest a workaround or fix it.
Hi,
If this is a locally built project, the regular VS verbosity setting (Tools->Options->Projects and Solutions->Build and Run->MSBuild project build output verbosity) should get VisualGDB to show the command lines. Alternatively you could simply check the .rsp files (they contain saved command lines). The regular Visual Studio Command Line page won’t show the custom options.
Please also ensure you are using the latest VisualGDB 5.2r9.
OK, we would need to run a few tests of this on our side.
Would you be able to detach the problem from any confidential code and send it to us? E.g. preprocess the file to a single source file, confirm that the problem still happens when opening it and then start removing the parts of the file until you pinpoint the exact declaration that causes this. Using binary search, this should take only a few iterations.
