cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with assert_param

litus0801
Associate II
Posted on March 24, 2010 at 20:39

Problem with assert_param

19 REPLIES 19
Andrew Neil
Evangelist III
Posted on May 17, 2011 at 13:44

''The compiler return first error''

 

 

What error, precisely, is that?

litus0801
Associate II
Posted on May 17, 2011 at 13:44

Oh! Sorry, I would mean this line:

#error ------------------------------ assert full def.

Andrew Neil
Evangelist III
Posted on May 17, 2011 at 13:44

Sorry - what was your objective in doing that?

litus0801
Associate II
Posted on May 17, 2011 at 13:44

The fact that you're getting neither the ''full'' definition nor the ''null'' definition  suggests that you are not actually including this at all...

My aim was to know if the macro was defined or not, and which one.

In fact, now, what I did to temporary solve the problem was comment ALL the

assert_param

lines. As it's not a strictly necessary part of the library I just skipped it... I know that this is not the point, but it works now. Have you any other idea?
Andrew Neil
Evangelist III
Posted on May 17, 2011 at 13:44

You shouldn't need to do that - so it's an indication that there is something fundamentally wrong with the way you've goy your project set up.

You might be lucky, and this might be the only thing that's affected - but I think it would be better for you to understand what's actually going on, and to fix it properly.

As already noted, this is a standard 'C' programming technique - if you try to skimp understanding it now, it will just come back to bite you again later!

Andrew Neil
Evangelist III
Posted on May 17, 2011 at 13:44

It's highly unlikely to be a compiler bug - far more likely a project set-up issue.

I don't know IAR, so can't comment specifically on that - but this really is basic stuff, so someone would certainly have noticed by now if there were a bug!

The symptoms sound like the definition is not visible at the point where the macro is used - which most likely means that you have forgotten to include a header, or include the wrong header somewhere...

Can you get any of the sample projects to work unmodified ''straight out of the box''?

litus0801
Associate II
Posted on May 17, 2011 at 13:44

You are completely right, but neither me nor the people I asked are able to understand what the hell is happening here... I will try to ask to IAR support because perhaps it's a compiler bug. I don't know, do you?

Greetings,

Carles Araguz

x_stm-forum_x
Associate II
Posted on May 17, 2011 at 13:44

Hi,

I'm seeing the same (or similar) problem.

Adding #error to a header file proves nothing unless you look close enough. ;)  Sure it may show that header file is being included, but not necessarily as part of the compilation unit that complains about assert_param.

The macro assert_param() is defined in stm32f10x_conf.h (comments snipped for brevity):

#ifdef  USE_FULL_ASSERT

  #define assert_param(expr) ((expr) ? (void)0 : assert_failed((uint8_t *)__FILE__, __LINE__))

  void assert_failed(uint8_t* file, uint32_t line);

#else

  #define assert_param(expr) ((void)0)

#endif

These are the compile errors:

stm32f10x_rcc.c: In function 'RCC_HSEConfig':

stm32f10x_rcc.c:282: warning: implicit declaration of function 'assert_param'

stm32f10x_gpio.c: In function 'GPIO_DeInit':

stm32f10x_gpio.c:110: warning: implicit declaration of function 'assert_param'

It is clear that assert_param is not defined, and therefore stm32f10x_conf.h could not have been #included for these compilation units.  This suggests that no amount of tweaking the preprocessor macro definitions is ever going to fix this - although I may stand to be corrected.

Afaict, stm32f10x_conf.h is intended to be copied into the user application where it may be customised, whereas stm32f10x_ppp.c (21 files in total) are the 'library' modules (albeit individually linked).

I've grepped the library tree and the *only* place I can find #define assert_param is in the template stm32f10x_conf.h file, but assert_param() is used throughout the library modules.  Further investigation suggests that there might be some mechanism in the #include nesting that allows for stm32f10x_conf.h to be included by each stm32f10x_ppp.c file, but I haven't managed to get to the bottom of it yet.

I'm new to STM32 (but not C :-p) and I just don't see how this framework is supposed to work - any insight to this would be much appreciated.

The library files and demo examples are taken from here - http://www.st.com/stonline/products/support/micro/files/stm32f10x_stdperiph_lib.zip

ps. sorry if the formatting is off, or if it's already been answered elsewhere.  I was googling for an answer and found this recent thread, hence the rapid sign up and post.

x_stm-forum_x
Associate II
Posted on May 17, 2011 at 13:44

Ok, I think I've found the solution to this.

Define USE_STDPERIPH_DRIVER in the pre-processor macro definitions, and it causes the necessary header file nesting to pull in the assert_param() macro definition.

Can anyone can point me to the RTFM where is says to do this?  There's probably more to know that isn't obvious.

The project compiles without warnings now at least, although not tested yet. :)

litus0801
Associate II
Posted on May 17, 2011 at 13:44

Yes! You found the solution!!! Thanks a lot!

Unfortunately the reference manual doesn't say anything about it... The only doc we have is the help file manual and that sucks... Well, at least I think that this is not explained anywhere. Maybe it is but is impossible to find it...

Again thanks x.x.001!