[Ancaritha]

Well, no luck finding it.  Fun fact, though, there is a file in C:\SysGCC\arm-eabi called  IntelliSense.props.  In that file is the line:   __INT32_TYPE__=long int   It also has matches (according to grep) in the cc1.exe and cc1plus.exe files, but since they’re binary it doesn’t show me the outputs.

Unless you guys have any other ides, I think I’m just going to turn off the Wformat warning…

[Ancaritha]

I suspect that VisualGDB is the one that is correct, which makes me wonder exactly what GCC is compiling against…

The first one brings me to:    typedef __int32_t int32_t ;    in _stdint.h (c:\SysGCC\arm-eabi\sys-include\)
Go to on __int32_t brings me to:

#ifdef __INT32_TYPE__
typedef __INT32_TYPE__ __int32_t;
#endif

in _default_types.h (c:\SysGCC\arm-eabi\sys-include\machine\)

From there, right-click Go To Definition doesn’t bring me anywhere.  However, while searching around for that, I found it in the gcc_debug.h and gcc_release.h files:

#ifndef __INT32_TYPE__
#define __INT32_TYPE__ long int
#endif

Initially this looked like the culprit, but I manually edited both files (just in case) and threw in some gibberish inside of that ifdef and did a rebuild and it didn’t crash, so I don’t think that’s active.  Just to make sure, I completely removed that entry and did a rebuild.  No change.  And just to really really make sure, I changed them to long long ints, no change.

So that means somewhere  __INT32_TYPE__ is being defined… I just have to find it.  I did a search in Windows Explorer in my solution folder, the entire SysGCC folder and the entire drivers folder in the STM32L4 framework, and it didn’t find anything (which I know is a lie, since it should have found the gcc_debug.h file at the very least).  So now I’m going to go refresh my memory on how to use grep on Windows…

[Ancaritha]

On further evaluation, that doesn’t actually make sense.  The /include folders aren’t in my path, so it shouldn’t be able to find them that way.  The compilers must be referencing them by relative path.  Soooooooooo, back to square 1.

[Ancaritha]

Ok… I do have multiple compilers on my computer, and one of them does define “int32_t” as a “signed long int” inside of it’s stdint.h

 

Since SysGCC is not in my systems path file and it’s only ever referenced by $(TOOLCHAIN_ROOT), I bet this is the problem.  It’s looking up those header files and it’s finding the ones in my path rather than the ones in SysGCC.

[Ancaritha]

Ok, so this is expected behavior.  That’s good at least 🙂

Being able to scan the entire project will be super awesome, but this is at least a good for step for me to turn on and leave active.

 

Thanks!

[Ancaritha]

Hmm, I already am a stand alone project that doesn’t reference any files from the BSP.  There must be something messed up in the backend that’s causing this to happen.

Ok, I played around with purging stuff from various files, and I found something that stops it from regenerating the BSP files (which any reference too have now been removed from the .vcxproj and vcxproj.filter files).

In stm32.xml there was a section called “AdditionalHeaderFiles” that had entries like:<string>$$SYS:BSP_ROOT$$/FreeRTOS/Source/CMSIS_RTOS/cmsis_os.h</string>

I manually removed that entire tag and re-opened my solution, everything loaded fine and when I manually regenerate the MCU files it doesn’t make the BSP files again.  Yay!

[Ancaritha]

Second bug:

Every time I regenerate the MCU files, it modifies my vcproj.filters file with things like

<ClInclude Include=”$(BSP_ROOT)\STM32L4xxxx\CMSIS_HAL\RTOS\Template\cmsis_os.h”>
<Filter>Device-specific files</Filter>
</ClInclude>

 

It does this even if those entries already exist.  I made no changes to any of my settings and just selected “Regenerate MCU files” and then hit “Apply”.  I did this about 5 times, and after each time the diff between the two versions got larger and larger as it appended things that already exists.

 

Also… is there any way to turn that off (on either 5.3R8 or 5.4)?  I don’t want it to automatically generate those files, I find it super annoying as that’s not how my code structure is set up.

 

[Ancaritha]

My apologies in advance for the somewhat odd post.  I am writing this as I am testing different things so it’s a bit more stream of thought as I figure things out…

I created a new embedded project and added this to int main and it worked (i.e. I got the pretty Clang output warnings).

int x;
x |= 1;

After I did that, I went and added the same lines of code to an existing project and it… kinda worked.  I got the same warnings about an uninitialized variable, and a couple others about overloaded virtual functions in another headerfile.  Those overloaded virtual function warnings did not appear last time I tried turning on the Code Analytics, so I don’t know why me creating an embedded project should have made any changes…  I also only appear to be getting 9 messages, and I’m guessing I should have way more since I have 125 GCC warnings.

I have confirmed that the Code Analyzer settings are the same and the VisualGDB IntelliSense Settings are the same (see image below) between the new project and my existing one.  Are there any caches I should be clearing or have I sometime in the last year or two clicked some setting in VS that would have changed Clang or something to that effect?  I deleted the .sdf file for the project to force a reparsing and I still get the same warnings as before.

Ha!  I think I figured out why it doesn’t seem like it’s working.  I added that same code to 2 other files in my project, and the Clang warnings/messages don’t show up unless that is the file I am actively viewing (and any headers it calls).  If I’m not looking at one of those files, that uninitialized variable message doesn’t show up.  As I start clicking around the solution with the Error menu active, different warnings start showing up!  So I guess the final question is, is that expected behavior?  If not, how can I make it always display the warnings for all files?  This project has 200+ files,  clicking on each one would be extremely tedious…

Thanks!

• This reply was modified 5 years, 11 months ago by support. Reason: formatting

Attachments:

You must be logged in to view attached files.

[Ancaritha]

I originally tried changing just the exe and that did not resolve the issue, so I believe it has to be with the underlying scripts (or at least, it’s not just the exe’s fault).  I will turn on the verbose debugging and take logs when I get a chance.  Hopefully that’ll be later today but I’m not sure if I’ll get the chance.

[Ancaritha]

Just wanted to post a quick update in case anyone else was having this issue.  I finally got an eval board of an L073 and that has the same issue as my board, so it’s definitely an OpenOCD problem.  I checked the two print outs and the clock speed didn’t change but the expected flash size did change from 128Kb to 96Kb, so it may have to do that.

[Author]

Posts