STM32CubeMX V4.13.0 problems

Mackay.Susan · ‎2016-02-06

Posted on February 07, 2016 at 04:30

Yesterday I upgraded to V4.13.0 which required that I also upgrade to STM32CubeL4 V1.3.0.

Since then, every project that I generate exhibits a couple of problems:

1) every reference to RCC_xxx #defines shows up in the IDE as ''Type RCC_xxx could not be resolved''. Same with anything that looks like it could be a system defined preprocessor symbol. The programs compile OK so I think this is an issue with the generated code for the project

2) every program starts in debug and, before it gets to the 'main' function, ends up in the ''startup_stm32L476xx.s'' file at some labels called ''Default_Hander:'' and ''Infinite_Loop:'' where the executable code is exactly that - a branch back to the label. I have single stepped through the code form the ''Reset_Handler:'' label and the last statement seems to cause the problem is ''bi __libc_init_array'' in that I cannot step into that function and when I pause the processor I'm at the infinite loop.

The console shows:

===================================

Breakpoint 1, LoopFillZerobss () at C:/Users/Administrator/workspace/Blinky/Drivers/CMSIS/Device/ST/STM32L4xx/Source/Templates/gcc\startup_stm32l476xx.s:114

114 bl __libc_init_array

Program received signal SIGINT, Interrupt.

WWDG_IRQHandler () at C:/Users/Administrator/workspace/Blinky/Drivers/CMSIS/Device/ST/STM32L4xx/Source/Templates/gcc\startup_stm32l476xx.s:134

134 b Infinite_Loop

===========================

Have I done something or not done something that has caused this?

Susan

Mackay.Susan · ‎2016-02-22

Posted on February 23, 2016 at 03:01

Thanks - I'd like to try that. However, are you referring to the 'LinkerScript.ld' file or 'STM32L476VGTx_FLASH.ld' file. Looking at your code, I can't see that it is a modification to either file (yours looks totally different to either of those files and I don;t have the knowledge to determine if they really are the same) and a search of all of the generated files does not show the

''__stack'' or ''_estack'' symbols

.(Edit: oops - actually I can see the '_estack' but not the '__stack' symbol)

However, and with all due respect, I do not think a work-around is the correct way to go.

If this is a 'bug' then it needs to be acknowledged and fixed.

If it is NOT a bug, then I really would appreciate knowing what I am doing wrong to get into this situation.

Susan

ChrisH · ‎2016-02-22

Posted on February 23, 2016 at 06:20

replace content of STM32L476VGTx_FLASH.ld with this file and it works. _estack in cubemx linker is totally wrong and will get you into infinite loop. If you prefer to modify linker generated by CubeMX change RAM size to 96K and _estack to 0x20017FFF

stm32cube-t · ‎2016-02-23

Posted on February 23, 2016 at 11:27

Dear Susan,

The L476VGTx MCU has 2 RAMs and indeed the linker script is wrong and you should follow the recommendation:

RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 96K

CCMRAM (xrw) : ORIGIN = 0x10000000, LENGTH = 32K

This will be fixed in STM32CubeMX 4.14.

Thank you for the details you provided.

stm32cube-t · ‎2016-03-22

Posted on March 22, 2016 at 19:08

Please note STM32CubeMX 4.14 implements a workaround to the linker script issue on RAM descriptions: only RAM1 will be listed with 96k size. In a next release, both RAMs will be made available in the linker script.

Best regards