For some reason, when I generate code for an STM32F091VB board using CubeMX, it starts executing code outside of the code space if I include any HAL libraries. If I use LL interface instead, it runs fine. Is HAL broken on CubeMX 6.1.1?

[RWebe.7]

STM32CubeIDE version: 1.5.1, Build: 9029_20201210_1234 (UTC)

STM32CubeMX version: 6.1.1

[KnarfB]

Likely not. Startup code is assembler, you can set a breakpoint at Reset_Handler in the Startup tab of your debug configuration and check.

"it starts executing code outside of the code space" means what? How did you fnd out? Whats happening?

[RWebe.7]

It starts executing, but when I pause, I see that it's outside of the code space. See attachment. This code was generated with CubeMX, with all peripheral interfaces set to LL in Project Manager -> Advanced Settings, except for TIM. I just chose that one to be HAL to demonstrate the problem.

However, if I make all interfaces LL, I can let it run indefinitely. When I pause execution, it's in the while(1) loop in main. This seems to operate normally, so I don't think it's a problem with the start-up assembly code. It does execute main in this case.

[KnarfB]

If it is a custom board: are the boot pins properly set?

[TDK]

That's within the system bootloader memory.

Step through the startup code and see where it goes wrong. Could be a heap/stack overflow causing the problem. Unlikely to be a glaring error within HAL.

[RWebe.7]

Yes, @TDK​ , it was a problem with the bootloader. PF11_BOOT0 was pulled high. That, along with some reg bits nBOOT0 and nBOOT1 being high, meant that the bootloader was executing. What's strange is how the execution of the bootloader didn't happen right away. Maybe there's a time factor involved too. I haven't dug into the bootloader because we don't plan on using it.

Setting nBOOT1 to 0 in main didn't help, at least not while debugging, which introduces time delays. PUlling PF11_BOOT0 low did fix the problem.

The reason this seemed related to HAL was probably because of the added time HAL initialization takes than LL initialization. Also, as soon as I started stepping into the code, now the time is affected too. An interesting complication.

Anyway, that was the problem. I'm up and running now. Thanks.

[TDK]

I'm not sure that explanation makes sense. Either the chip starts in the bootloader or it doesn't. It doesn't matter what user code is on there.

Note that the debugger will circumvent the boot settings by explicitly telling the chip where to start.

In any case, glad you got it solved.