This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Static variables and MULTIPLE CALL TO SEGMENT warning

Every so often I get the L15: MULTIPLE CALL TO SEGMENT warning. In some functions it's warranted, but for some functions I don't understand what's happening. Here's an example of such a function (not a real function, but close to what I have in my code):

void Refresh(void)
{
    uint8_t buf[4];

    if(4 == Calculate(buf))
    {
        DoSomething(buf);
    }
    else
    {
        // don't do anything here
    }
}

This function triggers the L15 warning. The functions that come up in the warning as the callers are ISRs that never call the function, not even indirectly, so it's a bit baffling. The ISRs also don't have any variables inside them, so there's no shared memory between them and the function that triggers warning L15.

The strange thing is that if I change the function to:

void Refresh(void)
{
    static uint8_t buf[4];

    if(4 == Calculate(buf))
    {
        DoSomething(buf);
    }
    else
    {
        // don't do anything here
    }
}

the warning goes away. Nothing I've read in the documentation related to static suggests that it would have an influence on that warning.

Can anyone help me out in determining why the compiler/linker behaves this way?

Parents
  • No, there are no clues in the m51 file, nor are the names conflicting (I also thought about this, so I changed the names, without any consequences).

    And I still don't understand why the compiler reports some of the ISRs as callers to the function that throws the warning. Some of them simply have no connection to it. If it really is a shared memory problem, I'd expect the compiler to at least give me a more helpful message.

Reply
  • No, there are no clues in the m51 file, nor are the names conflicting (I also thought about this, so I changed the names, without any consequences).

    And I still don't understand why the compiler reports some of the ISRs as callers to the function that throws the warning. Some of them simply have no connection to it. If it really is a shared memory problem, I'd expect the compiler to at least give me a more helpful message.

Children
No data