• State Resolved
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 52 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM263P4-Q1: How To Verify FreeRTOS FPU Support

Kier
Mastermind 9680 points

Part Number: AM263P4-Q1

Hello,

We're getting some strange floating point comparison behaviour in a static FreeRTOS task when it is interrupted by an ISR. The ISR itself also uses FPU.

I note in the SDK docs AM263Px MCU+ SDK: FreeRTOS the words "FPU save/restore is supported":

image.png

That stops short of saying it's enabled.

  1. Should I assume FPU context save/restore is always enabled?
  2. If not, what should I check to satisfy myself that it is enabled or that we haven't unintentionally disabled it?

Thank you.

  • +1
    TI__Mastermind 23922 points

    Hi Kier,

    Kier said:
    Should I assume FPU context save/restore is always enabled?

    This depends on what FreeRTOS variant are you using from the SDK? The SDK now offers an MPU aware FreeRTOS and the default non MPU FreeRTOS.

    Non-MPU Variant (ARM_CR5F):
    - FPU save/restore in ISRs is ENABLED by default (via ENABLE_FPU_SAVE_RESTORE = 1 in source/kernel/freertos/portable/TI_ARM_CLANG/ARM_CR5F/portASM.S:60)
    - FPU save/restore in task switches is OPT-IN per task - each task using FPU MUST call vPortTaskUsesFPU() before executing any floating point instructions
    - If your static FreeRTOS task never called vPortTaskUsesFPU(), its FPU context is NOT being saved/restored during task switches

    MPU Variant (ARM_CR5F_MPU):
    - FPU save/restore is ENABLED globally for all contexts (ISRs and task switches) by default via configENABLE_FPU = 1
    - All tasks automatically get FPU context saved, with 132 bytes overhead per task

    Kier said:
    If not, what should I check to satisfy myself that it is enabled or that we haven't unintentionally disabled it?

    For this reply, I'm assuming it is the non MPU FreeRTOS variant, you could follow the steps below.

    1. Look at your project's makefile or build configuration to see if it links:
    - source/kernel/freertos/portable/TI_ARM_CLANG/ARM_CR5F/ (Non-MPU)
    - source/kernel/freertos/portable/TI_ARM_CLANG/ARM_CR5F_MPU/ (MPU)

    2. Check if the macro is set in portASM.S file (full path is: source/kernel/freertos/portable/TI_ARM_CLANG/ARM_CR5F/portASM.S:60)

    #define ENABLE_FPU_SAVE_RESTORE (1)

    3. Verify if you are compiling with the fpu flags, -mfpu=vfpv3-d16 or similar

    4. Does your task call portTASK_USES_FLOATING_POINT() .

    If your task doesn't call portTASK_USES_FLOATING_POINT(), its FPU registers (D0-D15, FPSCR) are NOT saved/restored during task switches, causing corruption.

    Regards,
    Shaunak

  • 0 in reply to Shaunak Deshpande
    Mastermind 9680 points

    That's excellent, thank you very much. Yes, we missed out the opt-in step 4 in our non-MPU OS.

    We think the corruption is solved.

  • 0 in reply to Shaunak Deshpande
    Mastermind 9680 points

    One last question  , is there a manual we should have consulted which might have provided this information please?

  • 0 in reply to Kier
    TI__Mastermind 23922 points

    Hi Kier,

    As far as I know, we do not have any such manual, I'll plan to create an FAQ on this to guide customers.

    Regards,
    Shaunak

  • 0 in reply to Shaunak Deshpande
    Mastermind 9680 points

    I eventually found a hint that we should have considered this:

    AM263Px MCU+ SDK: FreeRTOS usage guidelines