This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Implicit declaration is invalid warning for __set_BASEPRI() function in Keil

I'm trying to use a __set_BASEPRI function in Keil to set up interrupts in STM32F407 but the IDE shows warning "implicit declaration of function '__set_BASEPRI' is invalid in C99". The code compiles without any warnings or errors but the function doesn't work. I'm having the same issue with some other functions from cmsis_armcc.h. However, functions like __enable_irq and __disable_irq and a few other functions work fine.

How do I make the rest of the functions work? I tried a fresh Keil install on another PC and everything works fine, so this is probably an IDE problem, not my code. Reinstalling Keil (with manually deleting Arm folder) on my PC didn't help.

Also weird, when I click on "Go to definition" on all these functions, the IDE cannot find the source file for them.

  • implicit declaration of function

    You need to provide an explicit declaration; ie, a function prototype.

    Are you missing a header file, perhaps ... ?

  • As you noted, __set_BASEPRI() is a CMSIS function, defined in cmsis_armcc.h. This file should be visible in the list of included headers for your .C file shown in the project explorer view. You'd get a build error if you didn't have it included. It's included automatically when you have the CMSIS Core package selected.

    F12 won't show the definition until compilation builds the browse data. And it seems browsing doesn't work too well (at all?!?) when using ARMCLANG (default compiler 6), which I guess that you are. Use global find (Ctrl+shift-F) to find the definitions, or use ARMCC (default compiler 5). IDE warnings (red X) can lag corrected code -- trust the build output over the IDE warnings. Closing and reopening files can help get rid of laggy IDE warnings. 

    If you check the listing file for the generated code and you see 'msr basepri' where you call the function, then the function is being compiled correctly. If it doesn't do what you expect, you're likely executing it in non-privileged mode (e.g., after the RTOS starts) or giving it an argument that the hardware doesn't like. That's where the debugger comes in handy.