Yahoo Groups archive

AVR-Chat

Index last updated: 2026-04-28 22:41 UTC

Thread

Re: Sanity checking

Re: Sanity checking

2009-02-23 by Don Kinzer

--- In AVR-Chat@yahoogroups.com, David VanHorn <microbrix@...> wrote:
> In C, is there a simple way to test wether the system has
> run out of memory while the program is running?
Simple?  No.  But there is a way.  The issues involved depend on 
which resources you're using in your C program.  It also depends on 
whether you're using external RAM or not.  For the sake of 
simplicity, the discussion below assumes no external RAM.

To review, RAM is divided into three areas: 1) statically allocated 
data items (whether initialized or not), 2) the heap (from which 
malloc() allocates space) and 3) the stack.  The statically 
allocated data items are assigned addresses in low RAM, beginning 
with the first available RAM address (which value depends on which 
AVR you're using).  The heap begins just above the statically 
allocated data items and grows toward the high end of RAM.  The 
stack begins at the high end of RAM and grows toward the low end of 
RAM.  Naturally, bad thing tend to happen if the stack grows into 
the heap and/or the statically allocated data items.

You can exploit these facts to help determine when the RAM areas are 
colliding.  The basic idea is to "seed" the RAM used by the heap and 
stack and then examine the contents from time to time to see how 
much of the seeded area remain untouched.  If you're not using the 
heap, you can determine programmatically how much unused space is 
left by scanning upward from the end of the statically allocated 
data until you find the first location with content different from 
the seed value.  If you are using the stack, the problem is 
complicated by the fact that you have two dynamic areas whose ends 
can be higher or lower at any time.

The code below can be used to seed the heap/stack RAM space.  It 
will be inserted into the startup initialization sequence fairly 
early, just after the stack pointer has been initialized.  It could 
be placed in one of the other initialization sections but .init2 
should be suitable for most applications.  If you examine the .lss 
file after compiling/linking with this code added, you'll see that 
the resulting code appears several instructions after the initial 
startup instruction.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

#define USED __attribute__((used))
#define NAKED __attribute__((naked))
#define INIT2 __attribute__((section(".init2")))

extern uint8_t *_end;  // the end of statically allocated data
extern uint8_t *__stack; // the end of internal RAM

static void seedRAM(void) NAKED USED INIT2;
static void seedRAM(void)
{
#define SEED_VAL  0xcc
  uint16_t addr;
  for (addr = (uint16_t)&_end; addr < (uint16_t)&__stack; addr++)
    *(uint8_t *)addr = SEED_VAL;
#undef SEED_VAL
}

Sanity checking

2009-02-23 by David VanHorn

In C, is there a simple way to test wether the system has run out of
memory while the program is running?


-- 

"The very powerful and the very stupid have one thing in common. Instead of
altering their views to fit the facts, they alter the facts to fit their
views... which can be very uncomfortable if you happen to be one of the
facts that needs altering." Doctor Who, Face of Evil

Re: [AVR-Chat] Sanity checking

2009-02-23 by H. Carl Ott

On Mon, Feb 23, 2009 at 10:39 AM, David VanHorn <microbrix@gmail.com> wrote:
> In C, is there a simple way to test wether the system has run out of
> memory while the program is running?
>
> --

Just trying to get up to speed with C myself.  I think the standard
trick of getting an initialized var into a known location near the top
of ram, then check to see if your stack clobbered it is the simplest.

  Of course, you might be in bad shape at that point.


-- 
carl
--------------------------------------------------------
Henry Carl Ott   N2RVQ    hcarlott@gmail.com

Re: [AVR-Chat] Sanity checking

2009-02-23 by David VanHorn

> Just trying to get up to speed with C myself.  I think the standard
> trick of getting an initialized var into a known location near the top
> of ram, then check to see if your stack clobbered it is the simplest.
>
>  Of course, you might be in bad shape at that point.

Right.

I'm making the transition too.. I have tools for this sort of thing in
ASM, but this is a whole new game.

Re: [AVR-Chat] Sanity checking

2009-02-23 by wagnerj@proaxis.com

> In C, is there a simple way to test wether the system has run out of
> memory while the program is running?
>
>
> --
>
> "The very powerful and the very stupid have one thing in common. Instead
> of
> altering their views to fit the facts, they alter the facts to fit their
> views... which can be very uncomfortable if you happen to be one of the
> facts that needs altering." Doctor Who, Face of Evil
>

A variant of this question was just raised on AVRFreaks. Folks with a lot
more knowledge than I have weighed in. Link is:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=74865

Jim

Re: Sanity checking

2009-02-23 by Don Kinzer

--- In AVR-Chat@yahoogroups.com, wagnerj@... wrote:
> A variant of this question was just raised on AVRFreaks.
The particular thread that was referred to dealt more specifically 
with RAM use issues specific to C++.  The more general issue of 
estimating RAM requirements (including maximum stack use) has been 
addressed in other threads including the two below to which I 
contributed some observations based on my experience with the 
subject.

http://www.avrfreaks.net/index.php?
name=PNphpBB2&file=viewtopic&t=70486.

http://www.avrfreaks.net/index.php?
name=PNphpBB2&file=viewtopic&t=71093

As I mentioned in one of the threads, we have created a static 
analysis tool that estimates the maximum stack use of an execution 
thread beginning at a specified Flash address.  We use this in our 
ZBasic compiler to determine the amount of RAM required for each 
task of the user's program.  Because we are in control of the 
generated code, this represents a specialized use case where we can 
deal with the issues that cause problems in static analysis of RAM 
usage (specifically, recursion, indirect calls (ijmp, icall), 
interrupt service routines).  A generalized tool that could analyze 
an arbitrary executable is significantly more difficult to implement.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.