Hi,

No problem, we can help you. First of all, please try to narrow down the problem to a specific source file (you can compile just one source by pressing Ctrl-F7 if using MSBuild). Then build just that file and check the error list (please turn off IntelliSense errors for the beginning and only look at build errors).

If you see a “header file not found” errors before the “DMA_HandleTypeDef” error, please locate the missing headers and add the corresponding paths to the project’s include directories. If no such errors are shown, please enable the “generate preprocessor output” option for that source file via Visual Studio Project Properties -> C/C++ -> Outputs and check the preprocessor output (.E file in the VisualGDB\Debug folder). It should list all headers included while building the file and the lines from those headers that were not #ifdef’ed out. If DMA_HandleTypeDef is not defined there, it might be due to including an incorrect header file, missing some HAL_XXX_ENABLED macros, that would exclude the actual definition, or missing #include<> directives altogether. If you need further help with this, please let us know your findings (build error messages, preprocessed file contents, etc) and we will provide further help.

We will consider supporting more detailed fine-tuning of additional memories in the next releases of VisualGDB. As a workaround, please consider adding any other memory (so that VisualGDB creates a local copy of the linker script) and then manually adding the QSPI sections there. Also if you already have a working GCC-based project in a different IDE, please consider simply copying an existing linker script from it and setting it via VisualGDB Project Properties. This should provide easier transition, as it will eliminate the differences between the linker scripts.

The _WIN32 macro is only shown if you are using the regular VC++ IntelliSense. Please consider switching to VisualGDB-provided Clang IntelliSense for better compatibility with GCC-specific code. Regarding FreeRTOS, if you were using the HAL/FreeRTOS packages that come with VisualGDB, it would display a more meaningful error message in case of HW/SW floating point incompatibility (we have added a check with an #error directive to our version of port.c), but using an incompatible 3rd-party copy of it unfortunately indeed results in cryptic error messages.

Hi,

Good to know it works. We should be able to fix the crash with aborting the FLASH downloading if you could obtain the context of the crash as described here (alternatively we would need a detailed description of your configuration, as FLASH can be programmed using several different mechanisms and it’s hard to say which one is causing the crash).

We are actually working on a redesigned system of custom actions for the upcoming VisualGDB 5.4, that will include better support for reusing the actions.

MSBuild is indeed faster than GNU Make – we have spent considerable effort optimizing our MSBuild backend, so it uses heavy parallelization and minimizes the overhead of auxiliary tasks like managing dependencies.

The idea of writing an article about ToughGFX sounds great – feel free to share a link to it on our forum.

Hi,

Please use the following setting: Tools->Options->Text Editor->C/C++ (VisualGDB)->Other->Max. change-driven tags.

Simply set it to 0 in order to disable rename-triggered smart tags.

Hi,

It looks like VisualGDB loses synchronization between the source file contents in the VS editor and the contents as seen by the Clang engine.

Could you please check if closing the source file and reopening it solve the problem? Also is it specific to a certain source file, or does it occur randomly across the entire code base?

Hi,

Thanks for the detailed description. Most likely this is caused by some invisible characters near the line breaks that are interpreted differently by VS and by Clang.

If you ever get this problem again, you might be able to reduce it as follows:

• Add a line “void testfunc();” at the beginning of the source file (after #include-s)
• Replace each of the problematic line contents (without touching the area near the ending of the line) with a call to testfunc().
• Confirm that the problem persists.
• Delete all lines between the declaration of testfunc() and the problematic lines, and also all lines after it
• Remove references to your #include-d files.

If the problem can be still reproduced after reducing it to the test code, simply send us the repro file and we will check for the characters causing it and should be able to add a workaround.

Hi,

Thanks, looks like you are using a single-byte encoding for international characters that is not properly supported by the Clang engine. Please consider saving your source files in the UTF-8 encoding instead (via File->Save As).

Good to know it works. The IntelliSense cache uses incremental snapshots, so it will normally only reparse the changed files (if you are editing a header file included from multiple source files, it will invalidate all of those source files).

If you believe too many files are re-cached, please try the following:

1. Open Clang IntelliSense Diagnostics Console and clear the log
2. Edit one file and trigger the cache rebuild
3. Let us know the file you edited and share the output shown in the Diagnostics Console. It should normally mention why the cache is being rebuilt, so we can help you understand what is going on.