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

Problem on debugger with extern variable

Hello everybody,
I have a problem with a global variable. This variable is declared as extern.
It is reset to 0 automatically inside the Keil µVisionb 4 debugger when used in a function written in different C file.
I make deeper reference.

I declared variable in a header like this

#ifdef __VAR_G
        #define __DEF
#else
        #define __DEF extern
#endif

__DEF uint32_t SystemCoreClock;
__DEF   uint32_t Init_OK;

I use this variable twice :
Firstly in a.c file

#define __VAR_G
#include "stm32f4xxiut.h"
void SystemInit()
{
    Init_OK = Init_OK | HSE_FAIL;
    SystemCoreClock=16000000;
}

Secondly in b.c file

#include "stm32f4xxiut.h"
void main()
{
    int b=0;
    if (Init_OK==1)
        b=2;
}

My problem is the following.
In the keil debugger, with STM32F4XX, first, system init is executed. The both variable are declared as global and a value is assigned to them. Then, the core branch to main and the both variable are reset to zero in spite of the extern keyword used inside the definition.

Do you know why there is this strange behaviour.

Thank you.

Parents
  • Just note that the Cortex chips have a design where the processor sets up the stack, allowing a C function to get activate directly on reset with zero assembler instructions involved. And the core performs the required background stuff to allow interrupt handlers to be ordinary C functions - no interrupt keyword needed.

    But if the reset code is written in C, that code must still be written based on the knowledge that the processor hasn't been fully configured yet and that C libraries etc can't be used.

    The C standard doesn't really consider C functions called before main() - it considers main() to be the entry function and specifies a number of rules that must be fulfilled at entry to main().

Reply
  • Just note that the Cortex chips have a design where the processor sets up the stack, allowing a C function to get activate directly on reset with zero assembler instructions involved. And the core performs the required background stuff to allow interrupt handlers to be ordinary C functions - no interrupt keyword needed.

    But if the reset code is written in C, that code must still be written based on the knowledge that the processor hasn't been fully configured yet and that C libraries etc can't be used.

    The C standard doesn't really consider C functions called before main() - it considers main() to be the entry function and specifies a number of rules that must be fulfilled at entry to main().

Children
No data