[Ancaritha]

I’m gonna ignore the 5th file.  I feel like you get the general idea at this point…

Attachments:

You must be logged in to view attached files.

[Ancaritha]

Ok, well the text files are too large to be uploaded, clocking in at an enormous 1.3 megs and 1.8 megs…  So i’m going to do it two different ways.

Full files using google drive (in case you want to look at everything all at once):
Here is the New (broken) version: https://drive.google.com/file/d/1B7g_HdNXt1BKeRnigwQTaDTLI5gMJwSI/view?usp=sharing
Old (working) version: https://drive.google.com/file/d/1636131gweiYT9em3aO28TmsUjIXy07lw/view?usp=sharing

I’m also attaching the files split into 3 and 5 parts respectively.  You can only upload 4 files at once sooooooooooooooooooo yea

Attachments:

You must be logged in to view attached files.

[Ancaritha]

Alrighty, I’ve attached two text files.  The “New” one is using the 2018-12-12 release of OpenOCD.  The “Old” is using our custom built one based off of 2017-04-14.

I placed a breakpoint at the first instruction of Main().  Using our custom built one, I’ll hit it every time.  Using the new one it never gets there.  If I pause the debugger and look at the hardware registers in the debugger and there are some… dubious values there.  R0 through R12 all have a value of 0xffffffff.  SP is 0x20004fe0.  LR is 0xfffffffe.  PC is 0xfffffffe.  I tried looking at the OpenOCD output but theres kind of a lot going on in there…

It should be noted that if I program the board using ST-Link and then do “Attach to running firmware”, it works fine.  It just appears to have an issue with programming the board.

[Ancaritha]

Heh, yup, found the old post: https://sysprogs.com/w/forums/topic/issues-using-newest-version-of-openocd-0-10-0/

Looks like I definitely dropped the ball, I’ll try and pick that up again now 🙂

[Ancaritha]

I’ve noticed that OpenOCD has issues with L0’s  (at the very least, the L071 that I use) if you are using a version after the 2018 release (before that works A-OK).  We had to update to the latest version to support the L496 processor and when I did that I stopped being able to program my L0 board.  We ended up manually building OpenOCD from a slightly older package and adding support for the L496 ourselves so that we could use both.

I recently decided to give the latest OpenOCD another shot and my initial test worked OK but recently I tried to use it again and it usually failed, so I started looking at this again  (I actually posted on the forums about this around a year ago but became swamped and was unable to experiment with it and just had to go with a known working).

When comparing the two OpenOCD outputs, I did notice something odd:

Old version (that works):
Info : Device: STM32L0xx (Cat.5)
Info : STM32L flash has dual banks. Bank (0) size is 128kb, base address is 0x8000000

New Version (that fails):
Info : Device: STM32L0xx (Cat.5)
Info : STM32L flash has dual banks. Bank (0) size is 64kb, base address is 0x8000000

 

Clock speed and adapter speeds match between the two versions.  Could this be as simple as the config file for the L0 is incorrect?

[Ancaritha]

Unfortunately I’m using make, so that’s not an option.  Oh well, disabling the warning it is.

Thanks for the help!

[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 6 years, 1 month 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.

[Author]

Posts