AVR Freaks

Thanks for the great post.
I was interested in monitoring the stack size of a subset of functions in my application.
Is there anyway I can paint the stack only up to the current stack pointer?
So that I can paint it right before calling the function I want to monitor and then doing the count after calling the function.

Could you please tell me what's going wrong?My stack usage is returning 5 bytes. I am using atmega169. I am filling my ram (0x100 to 0x4ff) with 0xaa value. Then I calculate my stack usuage. I have to find 3 consecutive occurrence of 0xaa values, so I can confirm that I reached the end of the stack. Is there any logical problem in finding 3 consecutive occurrence of 0xaa values in my implementation??Any help??

My asm:
#define MAX_MEM_ADDR 0x4FF

#define RAM_PATTERN ((unsigned char)0xAA)
/* The minimum number of times this pattern must occur consecutively in memory */
#define RAM_MIN_PATTERN 3
#define RAMSTART 0x0100

Thanks for this tutorial! Can this be used as it is for xmegas, or if not what needs to change? This is going to be very useful in my app as I need as much free SRAM as I can get for other buffers.

Mark.

I understand the principles are the same, but does the code posted work unaltered for xmega parts? If not, what needs to change in the code?

I will use this to monitor and measure stack usage, add a little contigency just to be sure and set the stack accordingly. Of course I'll use the standard techniques to reduce SRAM usage.

Yes, my bad. This is actually an LED display project and the more frame buffers I can allocate the better the system performance, so by 'set the stack' I actually meant make sure I don't allocate too many buffers such that the stack would over-write a buffer. The stack pointer would move down from the top of memory and my buffers would be allocated from the bottom up. I don't use the heap or malloc().

Mark.

_end should be __bss_end, according to http://www.nongnu.org/avr-libc/u.... I found that in my code it only produced meaningful results if I used __bss_end. I am using an XMEGA if it makes any difference, I have not tested it with MEGA/TINY. I don't use any memory allocation functions.

Thanks for this really useful bit of code.

Sorry for dumb question, but how should I use this StackPaint()? I mean if I call it in the beginning of main(), it executes and then I get a call to main() as subroutine back and so on and i get an infinite cycle. What am I doing wrong?

@MichaelMcTernan

Thank you for this useful piece of code and clear instructions. 6 years since your post you will be pleased to know, the information you have provided is relevant for some applications :)

I am using Atmega 2560 and planning to use your code in my project but there is one thing I am not too clear about.

In your code you have mentioned that __end and __stack need to be defined at the linker level for the monitoring application to work as expected.

The way I have done this is via the AVR Studio v4.19 as follows:

1 - Go to Project Options > Memory Settings

2 - Under "Stack Settings" tick the "Specify Initial Stack Address" and specify the setting as 0x8021FF

3 - Then go to Project Options > Custom Options

4 - On the left window of the "Custom Compiler Options", locate [Linker Options] and left click it.

5 - On the window to the right following should be displayed already, which is one of the linker options that will be used during compilation:
-Wl,--defsym=__stack=0x8021FF

6 - Similarly, I added the following option on the same window which defines the __end at the linker level:
-Wl,--defsym=__end=0x800200

I then clean built my code and checked the generated map file and confirmed that the following appeared in that file:

Linker script and memory map
Address of section .data set to 0x800200
LOAD c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr6/crtm2560.o
0x008021ff __stack = 0x8021ff
0x00800200 __end = 0x800200

Does the above meet the criterion on the __stack and __end you have mentioned?

Your quick feedback will be greatly appreciated.

Regards...

@clawson

Thank you for your clarifications. I thought by the following assignments I was merely assigning values rather than defining the symbols ( Though, I did correct __end as _end. Double underscore was my mistake! ).

-Wl,--defsym=__stack=0x8021FF
-Wl,--defsym=_end=0x800200

So to test that what happens if ı did not make this assignmenti I just removed the _end assignment above. I left the __stack assignment as this is provided as a valid user option in the linker configuration of AVR studio 4.19.

The code still worked as needed which means internally the _end assignment is done correctly for my device.

I presume the following line is where the _end is assigned its initial value in the avr6.x file
_end = . ;

Since I am not very familiar with the structure of the linker script files, I am unable to comment further. I think I will need to take a few things for granted for the time being.

One thing I am not clear on though is where is the __stack in the avr6.x file? The only reference to the keyword "stack" in that file is on the following line in that file:

KEEP (*(.init1))
*(.init2) /* Clear __zero_reg__, set up stack pointer. */

Regards...

This (thread subject) works! Thanks a lot!

Is there a better/modern way to do this? It doesn't work at all with avr-gcc 5.3 xmega. I tried with _end and __bss_end... StackCount always returns 0 even with an empty main().

Thanks! Got it working. The prototype for StackPaint() can't be in a header. Not that it needs to be but I guess gcc ain't that smart and even the gcc docs don't mention this?

Good news:

I've been able to run the code and it works perfectly. The not so good news are that, to do so, I had to manually edit one of the start-up files which get automatically generated by Atmel Studio on the project...

Canary function for AVR32 UC3:

/* Fill the stack space with a known pattern.
 * This fills all stack bytes with the 'canary' pattern to later allow
 * estimation of maximum stack usage.
 * This runs from the .init section, before normal stack initialization
 * and unfortunately before __zero_reg__ has been setup. The C code is
 * therefore replaced with inline assembly to ensure the zero reg is not
 * used by compiled code.
 *
 * This function must be called before the .text._stext section, which is
 * where all the stack initialization code resides. To accomplish that,
 * the start-up trampoline file (trampoline_uc3.S) must be modified, and
 * this function will be the one on charge of jumping to .text._stext after
 * finishing.
 *
 * Edit trampoline_uc3.S so it reads like this:
 * program_start:
 *     rjmp mem_canary_init
 *
 * To check that this function is working, just use the Debug mode called
 * "Start Debugging and Break", and open a Memory View on the address
 * 0x0000_FFFF (end of the SRAM space), so see that the canary value has
 * been written.
 */
void mem_canary_init(void) __attribute__((naked, section(".init")));
void mem_canary_init(void)
{
#if 0
    uint8_t* p = &_stack;
    while (p < &_estack) {
        *p = STACK_CANARY;
        ++p;
    }
#else
    __asm__ volatile (
        "    mov R8, lo(_stack)\n"  // p = &_stack
        "    orh R8, hi(_stack)\n"
        "    mov R9, lo(_estack)\n" // q = &_estack
        "    orh R9, hi(_estack)\n"
        "    mov R10, lo(0xC5)\n"   // v = STACK_CANARY = 0xC5
        "    rjmp .cmp\n"
        ".loop:\n"
        "    st.b R8++, R10\n"      // *(p++) = v
        ".cmp:\n"
        "    cp.w R8, R9\n"         // c = p < q
        "    brcs .loop\n"          // if (c) goto loop
        "    lda.w pc, _stext"      // Jump to the C runtime startup routine
        );            
#endif
}

Modified trampoline file (src\ASF\avr32\utils\startup\trampoline_uc3.S):

  // This must be linked @ 0x80000000 if it is to be run upon reset.
  .section  .reset, "ax", @progbits


  .global _trampoline
  .type _trampoline, @function
_trampoline:
  // Jump to program start.
  rjmp    program_start

  .org  PROGRAM_START_OFFSET
program_start:
  // Jump to the C runtime startup routine.
  //lda.w pc, _stext    // <----------- CHANGED HERE
  rjmp mem_canary_init  // <-----------|

Now it works flawlessly, but there is something to improve: I'd love to avoid having to modify auto-generated files. The beauty of the original solution on the first post is that it works as-is by just placing that function in any .c file. It just inserts itself into the .init1 section, which is already run by default.

I'd like to achieve the same for this function. Could anyone throw a comment on this?

Update: (Studio 7): The current end of the heap, as set by malloc(), is contained in __brkval;

modifying StackCount as following:

extern uint8_t *__brkval;

 

uint16_t StackCount(void)
{
  const uint8_t *p = __brkval;
  uint16_t       c = 0;

  while(*p == STACK_CANARY && p <= &__stack)
  {
    p++;
    c++;
  }

  return c;
}

 after a call to malloc() or calloc() will calculate the memory between the current top of the heap and the top of the stack.

I'm following the advice of some other threads on AVRFreaks: you can use malloc once at startup and then leave the heap alone. I don't churn the heap because I never free and re-allocate. Using malloc does simplify matters considerably, however, since the exact size of several arrays depends on parameters that aren't know until startup - they're controlled by configuration files in eeprom that can change if the setup changes.

In this case it's a user safety issue: I need to be able to verify that there's no stack-heap collision and that the margin is sufficient.

The AVR-libc routines work well and are optimized for AVR use.

http://www.nongnu.org/avr-libc/user-manual/malloc.html

Search AVRfreaks on "malloc", "c++", "free", "new", etc. Lots of debate back and forth.

I use "new" for objects (instances of classes), "malloc" for arrays. In the software I'm writing I have a lot of arrays of various things that are created at bootup. The software spends most of its lifecycle loop looking at input signals and searching the tables to figure out what to do with them.

Again, I'm not freeing any memory. The tables are set up once and then left alone. I wouldn't try any true dynamic memory operations on an ATmega.

Malloc may be optimized, but it damned well isn't optimized for what we and most embedded programmers want.  That is, to allocate everything at startup and hang on to them until the user pulls the plug.   The above code allocates memory in 4 simple lines.  I do put the enclosing brace on another line.  There's a story behind that if you want to know why.

Malloc has to deal with a whole lot of things that won't exist in embedded programs.  For instance, many discontiguous blocks of free memory.  It also has to know the size of each block when free() returns it.  And it also should merge free blocks with existing free blocks if they are contiguous.

Of course if your method is done in 4 lines of code or less, I'll admit I'm wrong. 

I'm sure there is a lot of stuff about C++ you can find here and around the internet, but a lot of it is nonsense.  For example, I've read here that avr-gcc C++ is experimental and shouldn't be used.  But I've been using it since I joined this forum 12 years ago and it always worked for me.

Actually the latest C++ is buggier than earlier versions in a certain instance I run into, but most people won't.  Interestingly this bug shows up in the latest Microsoft C++ as well.  I can't explain that one.