• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 54 subscribers
  • Views 1710 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Compiler/MSP430F2013: Compiler complains "Recommend moving function call away from ISR" on inlined function.

Gennadiy Kiryukhin
Expert 2800 points
Part Number: MSP430F2013

Tool/software: TI C/C++ Compiler

I have an inline function called from an ISR but the compiler still complains about it. Is that a bug in the compiler?

"../main.c", line 315: remark #1538-D: (ULP 10.1) ISR I2CISR calls function writecmd. Recommend moving function call away from ISR, or inlining the function, or using pragmas

The function is declared as 

static inline unsigned char writecmd(void)

and the output map file only shows my I2CISR and writecmd is not present in the list of content of .text section.

Is it looking for a particular way to inline the function?

  • 0
    TI__Guru**** 239845 points

    You have to build with optimization for function to be inlined.  Please build with the compiler option --opt_level=2 or higher.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Expert 2800 points

    Hello George.

    My optimization option is set to 4. In addition, I know that the function gets inlined because the map file does not list it as a separate function. To double-check, I looked at the asm listing and the function is indeed inlined.

    Regards,

    Gennadiy

  • 0
    TI__Expert 4930 points

    The remark is coming from early in the compilation, when the call from the ISR is detected, but before the compiler knows that that call will be inlined.  Unfortunately, I don't know what to tell you to do about it.  The compiler might be able to see the "inline" keyword at that point, but the actual inlining happens later so it still wouldn't know for sure.

  • 0 in reply to pf
    Expert 2800 points

    The message has instructions on how to address the warning (use inline, pragmas) but none of the suggestions work. It sounds like it is a bug in the compiler. There is a discrepancy between the warning message and how the compiler works. Based on what you are saying and the content of chapter "2.11 Using Inline Function Expansion" of MSP430 C/C++ Compiler User's Guide, there is no way to use inlined function inside an ISR without getting this message. The only recourse is to ignore/live with it (which defeats the purpose of the message) or to disable the check in the "--advice:power" options.

    It is interesting that the compiler creates function calls inside my ISR during size optimization. It is fine by me as there are lots of similar lines of code (ex. "send ACK bit and release I2C bus"). But at the same time it complains about the only function (I wrote it to separate the code structure) that gets inlined.

    I think TI needs to fix this confusion. Even the web page about this "advice" is implying that "inline or pragma" should work (although it is not clear which pragma I should use):

    processors.wiki.ti.com/.../1538

  • 0 in reply to Gennadiy Kiryukhin
    TI__Guru**** 239845 points

    To address this issue, I filed the entry CODEGEN-6671 in the SDOWP system.  This does not report a bug, but requests a change in the compiler.  In this case, if a function is inlined, the power advice about an ISR calling a function should not be issued.  You are welcome to follow it with the SDOWP link below in my signature.

    In the meantime, this ...

    Gennadiy Kiryukhin said:
    disable the check in the "--advice:power" options.

    ... is the best workaround.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Expert 2800 points

    As far as changing how the compiler works, if #pragma FUNC_ALWAYS_INLINE is used, would it be a problem to give a warning if the compiler is unable to inline the function?

    ... or, if a user specifies the above pragma, an the compiler is unable to inline a function, give another advice, ex. 10.2, "unable to inline a function in ISR". It could point to the section "2.11.2 Inlining Restrictions"  of the compiler manual that lists possible reasons. Although, I don't know if the part of compiler that performs inline-ing is aware of inlining inside ISR vs. inside of a regular function.

    The reason for the suggestions is so that the change does not diminish function of ULP advice and it is still detected.