• State TI Thinks Resolved
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 33 subscribers
  • Views 149 views
  • Users 0 members are here
Support feedback
Options
Options
Related

MCU-PLUS-SDK-AM243X: "warning: call to function could clobber interruptee's VFP registers; consider using the `interrupt_save_fp` attribute to prevent this behavior [-Wextra]"

Felix Heil
Expert 1195 points
Part Number: MCU-PLUS-SDK-AM243X

Tool/software:

Hello, 

we are currently updating to Industrial Comms SDK 11. In the past we did simply override the abort-hanlders of the sdk. Now the structure changed a bit and we get more information in user-abort-handlers.
We stayed with our old solution by just updating our overwriting implementation. so the modification is only that we do callback from the abort-handler, which in the end will reset the device. 

So we would anyway get an error with "warning: call to function could clobber interruptee's VFP registers; consider using the `interrupt_save_fp` attribute to prevent this behavior [-Wextra]".

But interestingly we also get it for most of the TI-code. Even calls to functions like GET_SPSR() and e.g. HwiP_getFIQVecAddr() produce this message. I did add the compile-options that are also set in the make-script of the sdk, but this didn't help. 

Is there a possibility to get rid of those warnings? I mean they don't seem to be a minor issue, since clobbering VFP registers can probably impact the interrupt-behaviour.

Best regards

Felix

  • 0
    TI__Guru* 77884 points

    Hi Felix,

    We have assigned this to our MCU Plus SDK team, will review internally and get back to you.

    Regards

    Karan

  • 0
    TI__Guru 50088 points

    Hi Felix,

    To avoid this warning, it's recommended to use the interrupt_save_fp attribute when defining functions that may be called from interrupt handlers and use floating-point operations. This ensures that the VFP registers are properly saved and restored, preventing potential issues.

    The syntax is defined below.

    Syntax - 
__attribute__((interrupt_save_fp)) <return type> symbol (<arguments>) { … }
__attribute__((interrupt_save_fp[(”interrupt-type”)])) void symbol () { … }

    Please refer cm-interrupt-save-fp-function-attribute for more details.

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Expert 1195 points

    Hey Tushar, 
    Yes, I thought of that. But I was curious why this is not already done in the SDK, since it complains about functions that are called which are inside the SDK and we did not plan to modify those functions.
    So since the sdk compiles and I've seen no complaints, I thought that maybe I am doing something wrong? We are compiling our overwriting-part as c++-files and the sdk as c-files of course, so is there a difference for this issue?

    best regards

    Felix

  • 0 in reply to Felix Heil
    TI__Guru 50088 points

    Hi Felix,

    You might be doing Floating point operation inside the ISR callback. FPU registers are not automatically preserved by the functions having "Interrupt" attribute.

    Please refer the below image.

    Regards,

    Tushar

  • 0 in reply to Tushar Thakur
    Expert 1195 points

    no, we are not doing that. 
    As I mentioned, this warning comes up, when I do no changes to the code at all, just copy the source-file HwiP_armv7r_handlers_freertos.c into our code-base, so it will overwrite the sdk-implementation. Of cours,e it's also compiled with c++-linkage, but extern "C" does its job here. 

    So with no modification of the code at all, it will complain about the call to GET_SPSR() which I mentioned in the entry post. That is a function provided by the SDK. we do no floating point operations or anything. 

    I want to know if I am doing something wrong, since the compilation of the sdk does not produce those warnings, but the exact same TI-code compiled in our code-base does, even if it does not use our code-base at all. 

    I don't want to modify the SDK and add this attribute to the functions GET_SPSR() and so on, since this means we will need to modify it all the time with every update. that's not our goal. 

    So is there an issue in the SDK, or is it me, that misses something out here?