STM32CubeMX v4.21 _Error_Handler definition issues in main.h

[Craig B]

Posted on June 08, 2017 at 02:02

Hi ST,

There are a couple issues with the definition of _Error_Handler() in main.h as generated in v4.21.0. 

First of all it needs to be wrapped as follows so it can be included in both .c and .cpp files with the correct linkage:

#ifdef __cplusplus
extern "C" { 
#endif
 
void _Error_Handler(char *, int); 
 
#ifdef __cplusplus
}
#endif
 
#define Error_Handler() _Error_Handler(__FILE__, __LINE__)

BTW, this should be done for all function definitions in all header files so they work correctly in both .c and .cpp files. I'm sure there are other cases. This is just the one I've run into.

Secondly, the _Error_Handler function is defined as taking a char * for the first argument. However, in gcc __FILE__ is a const char *, so in the macro in the header:

#define Error_Handler() _Error_Handler(__FILE__, __LINE__)

an error is generated. It should be:

void _Error_Handler(const char *, int);

Thanks,

Craig

[Imen.D]

Posted on June 15, 2017 at 14:13

Hi

Broadbooks.Craig

,

I reported this issue internally to our CubeMx team.

Thanks

Imen

[Craig B]

Posted on September 21, 2017 at 02:39

Hi ST team,

I just downloaded and installed the latest CubeMx version for windows and this issue I reported above back in June has not been resolved and a number of releases have happened since.  I know this seems like not a big deal.  However, may I remind you that anyone(including me) who includes main.h in a .cpp module as it is generated with CubeMx has a project that won't build due to the errors in main.h.  That makes this a Class A bug in my book.  If I had a developer on my team who continued to check in or deploy code that didn't build, they wouldn't be around long.  Why is this bug still here?  It means that I have a hand modified main.h that gets overwritten every time CubeMx generates code and I have to revert the necessary changes to it every time.  Not cool!  

Come on guys, you're better than this.

Craig

[Efim Ginter]

Posted on November 22, 2017 at 12:02

the problem is still not solved   

:(

((((

[Cyril FENARD]

Hi all,

ErrorHandler() signature is moving to function with no parameter in the future release.

As far __cplusplus guards are concerned STM32CubeMX has made improvements since several releases.

This issue could be closed.

Regards.

Cyril

[PLamo]

The fix for this is to add your own _Error_Handler() function to main.c and add macros to main.h:

#define GET_MACRO( _0, _1, NAME, ... ) NAME

#define Error_Handler(...) GET_MACRO( _0, ##__VA_ARGS__, Error_Handler1, Error_Handler0 )()

#define Error_Handler0() _Error_Handler( __FILE__, __LINE__ )

#define Error_Handler1(unused) _Error_Handler( char * file, int line )

void _Error_Handler(char *, int);

[PLamo]

So ST now has made it impossible to output the file and line of the error and this won't be fixed? What's next - generate fully broken code and say it will not be fixed in a future release?

This is broken. Code depends on the file and line of the error. A parameterless error handler is useless. Why would you make an critically important feature useless? No one can upgrade to the newer version of STM32CubeMX.

[Tesla DeLorean]

>>Why would you make an critically important feature useless? 

Exactly, good grief, who owns the validation and debugging tasks here?

Dumping into an infinite loop with no idea how it got there, how bloody insane is that?

You really can't do this in embedded equipment and expect to keep your job.

[PLamo]

We are talking about the elimination of the file and line parameters (which are called with __FILE_ and __LINE__) so you can know where the error occurred. It has nothing to do with the subsequent handling code. That's a different issue. The effect of your change is to switch from getting an error and knowing where it is in a large code base, to getting an error and having no idea where it occurred. I had to add some obscure macros to main.h to undo it:

void _Error_Handler(char *, int);

#define GET_MACRO( _0, _1, NAME, ... ) NAME

#define Error_Handler(...) GET_MACRO( _0, ##__VA_ARGS__, Error_Handler1, Error_Handler0 )()

#define Error_Handler0() _Error_Handler( __FILE__, __LINE__ )

#define Error_Handler1(unused) _Error_Handler( char * file, int line )

 In all places where the nulled function prototype is:

void Error_Handler(void);

It will be changed back to:

void Error_Handler( char * file, int line );

In all places where it is called:

Error_Handler();

It will be changed back to:

Error_Handler( __FILE__, __LINE__ )

You can then implement your own _Error_Handler() function (I put mine in main.c) which can output the error information.

[PMart]

Using MXCube 5.0.1 is it possible to configure the _Error_Handler prototypes from MxCube? i.e. using customized Templates?

The 2 parameters were essential to print out the source module and line that caused the trap... or we have to use the workaround proposed by @PPill​ ?