ISR only recognized if placed in a .c source file (.cpp housed ISR not picked up)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

ISR only recognized if placed in a .c source file (.cpp housed ISR not picked up)

Jump to solution
1,722 Views
edw8
Contributor III

I was prototyping the GPT demo code from SDK v2.3.1 in my current project. This is a C++ project which pulls in a static C++ library built as a dependency. While testing on the MIMXRT1050-EVK, I noticed my ISR was not hit while running in debug mode. I'm not sure if the project config has any bearings on the issue, but this project is setup to run from flash with SDRAM resources (stack and heap defaulting there).

The demo project with the same source code written for a C based project hit the ISR without issues. I ran a few tests trying to isolate the problem and concluded that the ISR itself is not recognized when the project is built with NewlibNano and the ISR body is part of a .cpp source file.

I generated a new project from the SDK, copied the code into its main source file (gpt_cpp_test_from_scratch.cpp) and built and ran the debug version on the MIMXRT1050-EVK. I only saw the GPT init code output. When pausing the project, I see the following trace:

2018-04-30_19-19-21.png

I modified the test project by adding a separate .c source file and relocated the ISR there. Running the project in debug mode with that change produced the expected runtime pattern, hitting the intended ISR code.

I included a build var (ISR_LIVES_IN_CPP) to serve as a build time toggle switch (in both C and C++ processor config areas in project properties) for seeing the two behaviors. Declaring the build var and building the project reveals the issue. Deleting the build var or changing its name and rebuilding allows the project to use the .c based ISR definition. The exported project is attached to this post.

I'm not sure why there would be an intentional restriction within to place ISRs in .c source files for a C++ project, but if this is the case, I would appreciate some background info regarding the restriction. Otherwise am I missing a config option for the project to handle .cpp based ISRs?

0 Kudos
1 Solution
1,530 Views
BlackNight
NXP Employee
NXP Employee

C++ does name mangling (see for example IBM Knowledge Center  or Name Mangling and extern "C" in C++ - GeeksforGeeks .

Typially the entries in the vector table are using "C" name encoding.

So I suggest that if you use your ISR in a Cpp file, you should add 'extern "C"' to it so it uses C name mangling.

I hope this helps,

Erich

View solution in original post

0 Kudos
3 Replies
1,531 Views
BlackNight
NXP Employee
NXP Employee

C++ does name mangling (see for example IBM Knowledge Center  or Name Mangling and extern "C" in C++ - GeeksforGeeks .

Typially the entries in the vector table are using "C" name encoding.

So I suggest that if you use your ISR in a Cpp file, you should add 'extern "C"' to it so it uses C name mangling.

I hope this helps,

Erich

0 Kudos
1,530 Views
edw8
Contributor III

Indeed that was my problem. So the original weak ISR had a prototype that was correctly bound within an extern "C" { ... } block . Creating a prototype for the ISR and including it in an extern "C" { ... } block did the trick. 

#if defined (__cplusplus)
extern "C" {
#endif

void EXAMPLE_GPT_IRQHandler(void);

#if defined (__cplusplus)
} // extern "C"
#endif

Placing the entire ISR within an extern "C" { ... } block also worked.

Thanks!

Ed.

0 Kudos
1,530 Views
converse
Senior Contributor V

I would guess that you have forgotten to define your ISRs as extern "C".

0 Kudos