[bug] SysTick_Handler optimised out of F4 HAL project

[mwp]

Posted on March 22, 2018 at 19:52

Hi all,

So i've been banging my head up against a wall trying to work out what's been going on here...

Somehow SysTick_Handler() and so HAL_IncTick() are being optimized out (or just not included) in my Release build.

The code/project runs just fine on the target STM32F401 when complied as a Debug build.

When built as a Release build (gcc options are below), the jump location for int15 (SysTick) is the Default_Handler.

I cant understand why this is happening. The HAL libraries are unmodified, and the 

HAL_IncTick() increments uwTick which is a volatile uint_32. I do use HAL_Delay(), so uwTick is referred to in the normal running of the program.

Has anyone come across this problem before?

The Release GCC options are:

arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=soft -Os -fmessage-length=0 -fsigned-char -ffunction-sections -fdata-sections -fno-common -ffreestanding -fsingle-precision-constant -flto -Wall -Wno-discarded-qualifiers  -DSTM32F4 -DSTM32F401xC -DUSE_HAL_DRIVER -DUSE_FULL_LL_DRIVER -DHSE_VALUE=16000000  -std=gnu11 -Wbad-function-cast

GCC version is:

arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 7.2.1 20170904 (release) [ARM/embedded-7-branch revision 255204]

Cube is latest version as of today, Cube F4 package version is: stm32cube_fw_f4_v1210.zip

#systick #stm32

[mwp]

Posted on March 22, 2018 at 20:20

To add to this...

Ive temporarily fixed the issue by commenting out the following lines in system_xxx.s:

.weak SysTick_Handler

.thumb_set SysTick_Handler,Default_Handler

I'm now having the same problem with the USB OTG int handler, so its not just limited to SysTick.

Any ideas?

[Tesla DeLorean]

Posted on March 22, 2018 at 20:37

Sounds more of an issue with the linker or linker script than being Cube's fault.

I'd start by looking if/why the vector table isn't being included or placed. An then the symbol attributes for the offending functions in objects they do exist in.

If C++ files or settings are being used watch out for name mangling, or explicitly use extern 'C' on the IRQ Handlers

[mwp]

Posted on March 23, 2018 at 18:33

Yes, you're right, it does appear to be a gcc/ld problem.

There is no C++ in this project at all, so that should not be the issue.

Using the previous version of the arm-gcc toolset fixes the problem.