Is .fpu incorrect in startup_stm32f411xe.s?

[Singh.Harjit]

In startup_stm32f411xe.s, the FPU seems to be incorrectly declared. It is:

.fpu softvfp

Shouldn't it be:

.fpu fpv4-sp-d16

I checked other files in the same family and they also have the softvfp declaration.

[Tesla DeLorean]

Is it throwing a warning at link time?

Do you actually have any FPU instructions in the start-up assembler?

[Singh.Harjit]

I'm not getting any warnings.

I don't have any FPU instructions in the startup code.

I do enable and use the FPU in startup code.

I was concerned about declaring incorrect / inconsistent FPU information with the rest of the code base.

[Tesla DeLorean]

I don't think this is consequential.

If you use FPU instructions in the file you'll need to pick a hardware options that covers the instructions in question, so things like push/pop of the float/double registers don't throw errors, for example.

[Tesla DeLorean]

If you want to edit it you can, obviously, but the linker is usually where the rules would be applied.

I'd personally be more concerned with the unaligned stack pointer stuff that is prevalent in ST's .ld linker scripts.

[Singh.Harjit]

I did edit it in my copy of the file.

Agree it is benign but given that this is the header file for a part that includes an FPU, it should be correct.

I feel for ST and other chip vendors around the complexity of supporting so many parts and families.

[pranjalk197]

Can you explain or point to somewhere regarding "unaligned stack pointer stuff"?

I was dipping my hands first time in assembly and startup file haunts me. It was soo much pain to enable and use ITCM as it required some assembly to move functions here.

[Tesla DeLorean]

So a thread pushing 5 years old

I mean nonsense like this in the older .LD linker scripts

/* Highest address of the user mode stack */
_estack = 0x2003FFFF; /* end of RAM */

rather than

/* Highest address of the user mode stack */
_estack = 0x20040000; /* end of RAM */

The ARM ABI wants an 8-byte aligned stack, but could probably live with a 4-byte aligned one.

Misaligned stacks half the speed of word accesses, and with LDRD / STRD will hard fault the machine. This is worse on CM0(+) which have even less tolerance for split transactions.

The stack ideally should be in the fastest memory available, and not external SDRAM, which can be 6x slower on uncached systems.

The SystemInit() routine should enable external memories so the static initialization works better.

One could use a symbol for the vectors to set SCB->VTOR and avoid having to change the code in multiple places.

The static initialization, copying the statics from FLASH into RAM, and zeroing RAM, could be done via a table. See how Arduino does it for GNU/GCC, or Keil via _scatterload and the Scatter files.

ST's heap allocation also assumes the heap extended from the top of the statics to the bottom of the stack, and they exist in the same memory region.

[Pavel A.]

> The SystemInit() routine should enable external memories so the static initialization works better.

If only this was that simple. For some external memories you need set up clocks, pins... and it doesn't fit in SystemInit anymore.

[Tesla DeLorean]

I'd argue that it's not rocket science, and if done properly there the MCU can be operated at full speed and efficiency from the outset, and the initialization not slow walked for no solid reason. Same thing with the tabular initialization, not as simplistic as what we've got, but it done once and properly, would work from the outset and not need constant rework.

Having faulting / error handling dying silently also not remotely helpful, could have had a decade plus of better code propagating outward, but no..