[Ancaritha]

It would appear that the incorrect target configuration file is being selected.  The “Debugged Device” drop down list just has the STM32L0xx option, which selects target/stm32l0.cfg

According to OpenOCD, approximately 2 years ago a patch was merged that makes it so now dual bank devices (such as the L07x) need to use a new configuration file, stm32l0_dual_bank.cfg.  When I manually switch to that file by modifying the command line options, it programs fine.

[Ancaritha]

I opened a ticket with OpenOCD and posted basically the same information I posted here.  If I hear back anything interesting I’ll update this thread so you guys are made aware of it as well.

 

Thanks!

[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.

 

[Author]

Posts