• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 81 subscribers
  • Views 607 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Function call in ISR

DavidG
Intellectual 290 points

Hello all,

I have an ISR configured for SCI-A receive that needs to execute some logic.  Currently this is what it does:

//ProcessHeartBeat(); // some reason the rx_buffer is cleared
uint16_t i;
for (i = 0; i < TXMSGLEN; i++)
{
tx_buffer[i] = rx_buffer[i];
rx_buffer[i] = RXUNINITIALIZED;
}

tx_send = 1;
rx_bytes_buffered = -1;

The contents of the commented out function call to ProcessHeartBeat() is 100% identical to the code below it.  All mentioned variables are global.  Basically it's echoing what I give it via software buffers.  This works perfectly fine in the current configuration, but if I try to replace the code with a function call for readability the rx_buffer variable seems to empty itself as soon as the debugger reaches the beginning of the call.  There are no doubly-defined warnings and I've manually checked scope to make sure that there is only ever one rx_buffer.  Is there something related to ISRs that would disallow access to functions?  rx_buffer is declared as:

static volatile uint16_t rx_buffer[RXBUFSIZE]; // RXBUFSIZE = 10 but this is pretty irrelevant for the question

Anybody know why the raw code works, but wrapped in a function it doesn't?  Thanks!

  • 0
    Intellectual 290 points
    Just in case there are others out there with this issue I've found a bit of a solution.

    Short explanation: Use an inline function.

    Longer explanation with lots of guessing:
    In most architectures I've come across calling functions within an ISR is illegal to begin with because of high overhead, but this architecture seems to allow it in appearance. It makes the call with no warnings or complaints but does not actually do what it says it is doing in the debugger. Declaring a function as "inline" will fix this issue and the code will execute correctly. The drawback that is introduced then becomes that the inline function must reside in the same file as the ISR. Declaring it as extern or even just separately in the header file does not work. Generally this agrees with the definition of an inline function that I am aware of but many compilers that I have come across will allow you to reference it from an external file. Ultimately I would guess that the linker is responsible for the inline functions' requirement to reside in the same file.