Build: 0 errors; IntelliSense: 126 errors

[Elliott]

Hi,

I’m starting a fresh project with VisualGDB and Visual Studio 2017 using code that was generated by STM32CubeMX, per the instructions at https://visualgdb.com/tutorials/arm/stm32/cube/.  At the moment, I haven’t done anything but create and compile the project, so the code here is 100% what gets pooped out of CubeMX.  I can run Build Project and it compiles with no errors from gcc.

BUT the code is full of red squiggly underlines because IntelliSense is having trouble finding declarations and definitions.

For example: at the bottom of main.c, there’s a void SystemClock_Config(void) function with the following block of code:

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
RCC_OscInitStruct.HSEState = RCC_HSE_ON;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
RCC_OscInitStruct.PLL.PLLM = 25;
RCC_OscInitStruct.PLL.PLLN = 336;
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
RCC_OscInitStruct.PLL.PLLQ = 7;
if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
{
Error_Handler();
}

All of the RCC_ variables are defined in stm32f4xx_hal_rcc.h, and the compiler finds them no problem.  IntelliSense seems to be aware of all project include directories, and in fact it finds RCC_OSCILLATORTYPE_HSE and RCC_PLLP_DIV2.  But it throws undeclared identifier errors for RCC_HSE_ON, RCC_PLL_ON, and RCC_PLLSOURCE_HSE even though they are declared in the same file, and if I click them and hit F12 it takes me directly to where they’re declared.  It is also having a hard time with type names like ‘uint32_t.’

I’ve tried manually adding all of the project include directories to the IntelliSense Directories config window, but that didn’t change any behavior.  I should also note that when I configured the project originally, IntelliSense seemed to have no awareness of the project’s include directories, even though “Automatic header discovery” is enabled, so I had to open files and look for the little yellow banner telling me that IntelliSense needed to add some include directories which were already part of the project.

Have I missed a setting somewhere that tells IntelliSense to look in the same place as gcc for header files?  As I said, the solution builds fine.  I’d rather not disable IntelliSense but at the moment it’s not adding value.  When this happened in Eclipse, I could do things like rebuild index, freshen all files, and so on and eventually it would figure it out (I’m using VisualStudio + VisualGDB specifically so that I don’t have to use Eclipse).  Is there a similar “try again” thing for IntelliSense?

Thanks,

—

Elliott

 

[support]

Hi,

Please ensure you are using the Clang-based IntelliSense and are not using 3rd-party plugins like Resharper as they are not fully compatible with GCC-specific code.

[Elliott]

As far as I can tell, I’m not using Resharper or anything like it.  Certainly not intentionally, and this is a clean install of Visual Studio – I don’t use it for anything else at the moment so there shouldn’t be extraneous plugins.

One other data point – while I was using the trial version of VisualGDB, I went through the project setup process 8-10 times using slightly different methods and had this happen 2-3 times, which is what leads me to wonder if it’s something I’m doing in the project setup that leads to this.

[support]

Hi,

No problem, we help you pinpoint this and find a workaround. Could you please attach a screenshot of the IntelliSense errors you are getting so that we could check if they look like any of the known issues?

[Elliott]

Sure, here’s a screenshot of the errors:

[caption id="" align="alignnone" width="1916"] screenshot of intellisense errors[/caption]

Remember that the 137 errors here are all IntelliSense; this is a successful build with 0 errors and 0 warnings otherwise.  The last error is “Error: too many errors emitted, stopping now.”

[support]

Hi,

Looks like the Clang IntelliSense might be having troubles locating some header files. Are you using a Makefile-based project or an MSBuild-based one?

Does changing the MCU forth and back (so that VisualGDB regenerates all settings) resolve this?

[Elliott]

It’s a Makefile-based project.  I should point out, though, that RCC_PLL_ON, RCC_LSI_ON, and RCC_HSE_ON are in the same file as RCC_PLLSOURCE_HSE.  Furthermore, when I launched Visual Studio this morning to get to work, the state is different.  Example – when I took that screen shot, it was able to find RCC_HSE_ON; this morning it is not.  Also this morning I see that in this line:

HAL_GPIO_WritePin(LED_RED_GPIO_Port, LED_RED_Pin, GPIO_PIN_RESET); // Clear red LED

IntelliSense is able to find LED_RED_Pin (line 76 of main.h), but not LED_RED_GPIO_Port (line 77 of main.h).  So that’s weird.  Every LED pin interaction I’ve looked at is like this – IntelliSense can find all of the _Pin defines, but none of the _Port defines, despite them all being bunched together in the same file.

[support]

Hi,

This could indicate a corruption of the Clang IntelliSense database files. Please try closing the project and removing the CodeDB folders under the the project directory.

[Elliott]

I didn’t try this yet, but I think I found the issue: I’m using a “third party” toolchain (GNU Tools ARM Embedded) which was installed in “C:\Program Files (x86)\GNU Tools ARM Embedded\[…]” so I was getting a lot of warnings that GDB gets confused by spaces in the pathname.  I made a symbolic link to it at C:\gcc to get rid of those warnings, and when I switched the toolchain all of the red squigglies went away and IntelliSense seems to be happy again.  So – maybe that was it.

[support]

Hi,

Yes, spaces in toolchain paths can cause strange problems, so we generally recommend avoiding them.

[Author]

Posts