Does STM32F469 bootloader correctly restore used registers to default reset values?

[TBran.15]

On a STM32F469, when jumping from DFU bootloader to main image, I have seen that the RCC_AHB1ENR register is set to 0x0 and not 0x0010 0000 which it should be after a reset, according to the documentation. This causes the CCM RAM to be disabled.

According to AN3156 the bootloader resets the register it has used to their default values.

Is this a bug in the bootloader?

[Tesla DeLorean]

It is quite likely that the loader will not return exact reset states. Hand-over states from your own loaders might also have non-reset states, including running HSE and PLL sources.

If you want to use CCM or stacks or whatever, enable it explicitly in the Reset Handler, enabling the FPU there is also good practice in-case down stream functions push FP registers to the stack.

For the SP, set the initial one (in the vector table) to 0x20020000 or some other valid/acceptable one, and then in-line enable the clock bits, and then set the SP to 0x10010000 or whatever.

[TBran.15]

Thank you.

Since the bootloader documentation states that all registers touched by the bootloader is set to default reset values before jumping to main image, it is a bug in the bootloader. If this, or other bootloaders, leave the processor in a different configuration than default, then, if I'm paranoid, I'll have to reset all registers in my application.

Is it important to have a valid initial stack pointer, as long as CCM is enabled inline as the first thing in the reset handler?

I think it complicates thing unnecessarily to configure the image to startup with a stack area, that is not at the intended location, and then change it during startup.

[Tesla DeLorean]

It is not that complicated in the scale of things.

Yes, it might be considered a bug, but you have to work with millions of devices as they are, not like you'd prefer them to be.​ Even if it got fixed today you'd still have a broad mix of devices in the field to contend with.