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

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

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

跳至解决方案
4,830 次查看
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 项奖励
回复
1 解答
4,638 次查看
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 项奖励
回复
3 回复数
4,639 次查看
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 项奖励
回复
4,638 次查看
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 项奖励
回复
4,638 次查看
converse
Senior Contributor V

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

0 项奖励
回复