Common #define between linker and source code

[cballard]

Posted on February 14, 2011 at 16:40

Common #define between linker and source code

[picguy2]

Posted on May 17, 2011 at 14:24

You may need a separate program to do this.  Perl should work nicely.

Put the address on the perl command line access with $ARGV[0].  Create two files.  One for C; the other to include in your linker script.  Or you could have perl find the address in your .h file and then create the include for the linker.

[Tesla DeLorean]

Posted on May 17, 2011 at 14:24

Is there some other way to do what I need to?

Not 100% sure of your goal, but I've always used the fact I can export the address of the vector table (__Vectors), and used that to program the NVIC. Where it goes then depends on where you tell the Linker to put the object code.                  AREA    RESET, DATA, READONLY                  EXPORT  __Vectors __Vectors        DCD  __initial_sp              ; Top of Stack                  DCD  Reset_Handler                  DCD  NMIException                  DCD  HardFaultException                  DCD  MemManageException ... extern void * __Vectors;     NVIC_SetVectorTable((u32)(&__Vectors), 0x0); // Smart Base Location

[cballard]

Posted on May 17, 2011 at 14:24

Clive

Thanks so much!  That's exactly what I was looking for! I needed this for 2 things: a) initialization of the NVIC table (we change its allocation when we start application code from our boot sector) and b) a self-imposed ''stack size checker'' routine that we generated that uses stack start address in the NVIC table to place a word near the top of the stack that we periodically check for corruption (pointing to a stack overflow issue). defining the NVIC table address externally in the linker file did the trick, THANKS!

[Tesla DeLorean]

Posted on May 17, 2011 at 14:24

I like my code to be as agnostic as possible to the address it compiles/runs at. And where it matters, to just have one symbol to reference, and not rely on changing multiple settings or defines that subsequent maintainers might overlook.

Well you could add startup code to pre-fill the stack with a initialization pattern, and then monitor how deep it actually gets. This can be examined periodically, or within a JTAG memory view window. You also place a magic word at the maximal extent (SP - 0x1FC, for example) and periodically monitor that for corruption. This is probably what you were talking about, I'd probably refer to it as the bottom of the stack as it is descending.