Data, idata confusion?

Static variables are those given fixed locations. Like globals and variables declared static. the rest (automatic variables) only exist while the function that declares them is in use. Most C friendly CPUs use the CPU's hardware stack for these variables. the RAM is reused after the function is exited.
Since the 8052 has a tiny stack Keil calculates the addresses for these variables and determines which can be located in the same location (Overlaying).

The compiler will handle this unless you are using function pointers, recursion, or calling functions from main and an interrupt.

A more like issue is that you ran out of RAM and the Stack is over writing the variables.

"The compiler will handle this unless you are using function pointers, recursion, or calling functions from main and an interrupt."

Note that the compiler doesn't take any specific account of these things - it's up to you to ensure that your application is "overlay-safe"

Effectively, "Overlaying" does at build time what "normal" compilers do (by using the stack) at run time.

The Compiler or Assembler mark data as Overlayable or not;

The Linker performs the actual overlaying:

http://www.keil.com/support/man/docs/lx51/lx51_overlaying.htm

http://www.keil.com/support/man/docs/bl51/bl51_overlaying.htm
http://www.keil.com/support/man/docs/bl51/bl51_in_overlaying.htm

Thanks Neil & Andy.

Hmm..I don't think I've done anything to blow the stack. I'm passing very little to my printf() functions, and that's the only time I've ever encountered stack overflow.

I think I understand how program data can be either static or overlayable, and that the toolset looks after combining any overlayable storage.

Please correct me if I am wrong. My AT89C51AC2 has 80 bytes, and a further 128 bits in it's DATA memory space. IDATA comprises of a further 128 bytes of storage. There is a tiny stack space in one of these storage regions, but I don't know how large it is, nor where it is located?

Previously, I have had too many variables occupying my DATA memory space, and there were consequently unwanted interactions between these variables. The situation was resolved by simply shifting some variables to IDATA. Now I would like to see if I have the same situation again.

Is it possible to determine the precise DATA and IDATA memory space occupancy from the static and overlayable memory requirements of the module set? (ie. from the figures quoted in the .LST files) Can I just add up the static and overlayable contributions from each of the modules to get total memory space consumption? Do I add the individual overlayable memory requirements from each of my modules as I would expect to add static requirements? Do overlayable segments somehow consume less than their sum?

Regards,
Murray R. Van Luyn.

That information is in the Linker Listing or "map" file.

"I'm passing very little to my printf() functions"

Did you miss the point that C51 does not pass parameters on the stack...?

Hi Andy,

Ah, I think I have it. Does the 'linker listing file' have a .M51 extension? I think I've found the answer you may have been pointing to in the following excerpt:

LINK MAP OF MODULE:  test_SD_Card (TEST)


            TYPE    BASE      LENGTH    RELOCATION   SEGMENT NAME
            -----------------------------------------------------

            * * * * * * *   D A T A   M E M O R Y   * * * * * * *
            REG     0000H     0008H     ABSOLUTE     "REG BANK 0"
            DATA    0008H     0002H     UNIT         ?DT?DCFS16
            IDATA   000AH     0006H     UNIT         ?ID?SD_CARD
                    0010H     0010H                  *** GAP ***
            BIT     0020H.0   0001H.1   UNIT         _BIT_GROUP_
            BIT     0021H.1   0000H.1   UNIT         ?BI?DCFS16
                    0021H.2   0000H.6                *** GAP ***
            DATA    0022H     003AH     UNIT         _DATA_GROUP_
            IDATA   005CH     0025H     UNIT         ?ID?DCFS16
            IDATA   0081H     0025H     UNIT         _IDATA_GROUP_
            IDATA   00A6H     0001H     UNIT         ?STACK

            * * * * * * *  X D A T A   M E M O R Y  * * * * * * *
            XDATA   0000H     0400H     UNIT         ?XD?DCFS16

I think I get how the linker deals with overlayable storage from that. It looks to me as though everything is in order and that nothing is overlapping. So that's not my immediate problem with the apparently incompatible modules. Crumbs, I wonder what is then?

Hmm, I once tried to pass too many variables to a printf() funtion and bad things happened. I'm maybe getting confused with that having something to do with some tiny stack overflowing. It was a long time ago.

Thanks for the direction to the linker output, Andy. That's answered my immediate questions nicely.

Regards,
Murray R. Van Luyn.

The documentation will tell if printf() has limitations.

A printf() that does not use a general stack for the parameters will not be limited by the stack size. But it will have other limitations. For example number of registers and number of fixed memory locations that may be used.