cancel
Showing results for 
Search instead for 
Did you mean: 

How to efficiently save and restore the 32F407 FPU context

Robmar
Senior III

STM should really post their code to handle FPU context saving and restoring BECAUSE their clients have been asking for over a decade!!!

One user stated "the time for a full FPU state save/restore is quite long. A pair of vpush {s0-31}/vpop {s0-s31} takes around 400ns on my STM32F407 @ 168MHz."

Without this our code suffers floats sticking at nan0x400 status after IRQs.

So, STM staff, come on, show us the best routine you have to save and restore the FPU status, because the Lazy FPU feature is useless!!

12 REPLIES 12
FBL
ST Employee

Hello @Robmar​ 

I come back to this old discussion and would like to mention that the FreeRTOS context switch routine is generic to any Cortex M4 with FPU. Here is an example how to save/store FPU registers in addition to lazy mode.

Added to that, ST provides this application note AN4044 section 3.5.3 FPU load/store instructions where we explained load/store instructions.

0693W00000aHKuWQAW.pngAlso, in Cortex-M4 Revision r0p0 Technical Reference Manual, you can find cycles counts of each instruction set.

It would be a good enhancement for our application note to include and detail the vpush/vpop instructions as load/store option for FPU. These instructions can potentially reduce the timing of FPU save/restore operations. (Any use case proposal from your side is welcomed, you can share your example privately if possible)

Thank you all for your constructive feedback.

Firas

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Thanks Firas, for the useful references, looks like it should be enough to complete two save and restore functions for the FPU. All the best

Hi,

Interested in your last comment about the toggle routine.

What's sub-optimal about it and what would be a more optimal version?

I use it quite a lot for debugging to keep track of timing etc,

I agree with you regarding RTOS and HAL.  RTOS is good for slow process control and I use it a lot and find it very good.  The support for FreeRTOS is also excellent, But if you need speed multitasking isn't an option because the processor is always busy processing IO. The other problem with the FreeRTOS is its footprint, that whilst small, on the really small low power processors I run out of memory.  I am making a much smaller version for the small processors mainly as a training exercise, but I am hoping to use it on all my small jobs.

I use HAL and then hack it to get rid of unused options and to speed it up. It's a bit rude, but I don't have the time to understand the nuance of every peripheral so HAL is a good starting point and my projects all seem to work.

Regards

Rob