0

While debugging an application, and finding that the ISR never actually enters, I checked the .map file and discovered that teh handler function is in the "discarded input sections", is there a way to force the linker to not do so? I'm sure it's a linker issue since I did not turn on any optimizations.

abraguez
  • 345
  • 3
  • 11
  • 1
    I think you need an attribute. [Something like this](https://stackoverflow.com/questions/60033340/can-a-fast-interrupt-handler-call-a-non-fast-interrupt-handler-function). – user3386109 Apr 07 '20 at 07:12
  • what type of embedded arm is this? a cortex-m? you specifically want that to be a normal (non-static) function no special compiler specific attributes. If it is not a cortex-m then it does need to be wrapped, but the linker wouldnt discard it willy nilly without the wrapper any more than any other function in any other file. – old_timer Apr 07 '20 at 12:25

1 Answers1

1

It is not a linker issue. This means that the compiler doesn't understand that the function is an ISR, but thinks it's a normal function. Normal functions that aren't called will not get linked, despite optimizer settings (or we'd end up linking the whole of the standard lib to the binary etc).

How to declare ISRs in gcc tends to be port-specific, generally you do as described in the gcc manual:

void f () __attribute__ ((interrupt ("IRQ")));

where the string part is MCU specific. Your specific MCU tool chain should document what specific names you should be using.

Lundin
  • 195,001
  • 40
  • 254
  • 396
  • if a cortex-m then you want it to be a normal function, assuming the compiler uses the proper abi. for gcc you want it left alone. global functions that are not called do get linked with the gnu toolchain if not in a library. In this case there would be a link to the vector/exception table anyway. – old_timer Apr 07 '20 at 12:28