STM32F733 startup with a CubeMX project

[GHolc.1]

I'm bringing up a new project using STM32F733, with code generated from CubeMX version 6.6.1, with difficulty. Looking for suggestions.

1) When I change the HAL timebase source from the default SysTick to something else, I've tried TIM2 and TIM10, then the call to HAL_Init() never returns, it runs out of stack. I've increased stack from the default 0x200 up to 0x2000, still runs out of stack. This is before any of my own code is called, only cube generated code.

2) Leaving the HAL timebase source set to SysTick, it steps through ok with the debugger (Segger J-Link). If I add a tight for loop doing nothing but incrementing a variable, stepping through, looking at the call stack, things look normal for a short while. The variable looks like it increments about 1,500 times when I let it run and then the micro starts stepping through unexpected code. The call stack showing nothing but __iar_SB + 0x1fcfed56, example, the offset from __iar_SB increments as it runs.

Where should I be looking? Hardware problem? Bug with something in HAL_Init() from cube? None of the ISR that usually catch errors are catching it. If I have the external clock configured, cubeMX checks the clock config and isn't showing any errors. The external clock stops, apparently as the same time as the code starts running instructions at __iar_SB + offset.

Update: Disabling SysTick from counting stops my call stack problem. Suspecting something isn't good with the interrupt vectors.

[Pavel A.]

Is your program called by a custom bootloader?

IIRC the IAR startup code does not initialize SP and relies on it being already set (by hw or bootloader) - unlike GCC startup.

[Tesla DeLorean]

Instrument and Debug

Make sure vector table is setup correctly and properly aligned.

Make sure the linker's bound the IRQ Handlers you expect, especially with .CPP (C++) compilation.

Establish what's actually failing.

Do you have excessive local/auto variables or arrays? Recursive code?

Use a fill pattern to determine actual stack utilization / max-depth

[GHolc.1 · Accepted solution]

Thank you Pavel and Tesla, your answers sent me down the right path.

The function SystemInit() which is called before main by startup code and contained in system_stm32f7xx.c was indeed not setting up the vector table correctly. The project that cubeMX setup for me contained an apparently obsolete version of system_stm32f7xx.c. I replaced system_stm32f7xx.c with a newer version of itself that I found in one of IAR's example projects for this micro and the vector table is setup correctly now.