Out of constant data space

We are using RCM6760. The message during compiling shown the code size is 292k bytes when compiled successfully. We like to add about 50 bytes string literals then got the following error:

line 1 : ERROR MEM.LIB : Out of constant data space. Please refer to the Dynamic C User’s Manual for more information.

The following is from the map file:
Root Code 0000:0000 003c76
Root Data 0010:33ae 0087c9
Xmem Code 0000:e760 04ba24

I believe 292k bytes is still under the memory size limit which is 1M RAM and 1M flash. Would you suggest any reason why getting this error?


1 Like

You need to start moving some of your constant data into far memory using the “far” keyword in the declaration.

There’s a good discussion in this forum question: https://forums.digi.com/29188/out-of-constant-data-space

One of the solutions for that poster was to list “ROOT_SIZE_4K=6U” in the project’s macro list. Be sure you have enabled “Separate Instruction & Data” space in the compiler options as well. You can take that macro up to 9U, as recommended in Device_Cloud.lib:

If defined, turns on debugging printfs for all Device Cloud subsystems. This can cause shortage of root constant space. If so, add ROOT_SIZE_4K=9U in the project defines box, and turn on the separate I and D option in the compiler settings.

And this Forum question provides some additional background information on memory configuration:

I used the two functions in my application code:

It shown me the memory usage as followings:

Root code+BIOS 15256 /47104
XMEM code 311574 /745472
Root constants 12032 /12288
Root variables 34763 /34816
XMEM variables 21334

It is clear that the Root constants and Root vairables almost up to the limit. So if I need to add more constant/variables in my application code, I have to add it to XMEM.

  • Are both Root constants and Root variables locate in on chip memory?
  • It doesn’t show the limit of XMEM variables. What is this limit?

On the Rabbit 6000-based products, everything runs from RAM, so root constants and variables are in that RAM. You might need to look at the MAP file to identify which variables and constants are eating up that space.

I’m not sure what the limit on XMEM variables will be, but my guess is over 400KB.

Note that with Dynamic C 10, it’s easy to place variables/constants in “xmem” by using the “far” property in the declaration. It’s possible you have a large array declared in root – adding “far” to the declaration will place it in xmem, and the compiler should warn you if you have any references to it that you need to update for the larger pointer size (for example, you cannot pass a ‘far char *’ to a function expecting ‘char *’).

Feel free to email me your MAP file and I’ll assist you via email. My address is my name, with a dot in the middle, at digi.com.

I read the document TN202 “Rabbit Memory Management in a Nutshell.pdf” page 4. Figure 1 shown that “base” and “xmem” are mapped on the flash. The “Data” is mapped on Ram. So “base” is Root code+BIOS and “Data” is root constants and root variable, is it correct?

If both root constants and root variables are in ram, is it on chip ram? I thought 6700 do not have on chip memory and all the flash and ram which is 1M are external.

The memory usage functions shown me there is 745472 for xmem code. And 6700 has 1M for ram/flash. Do xmem variables has size of 254528 instead of 400k?


In the RCM67xx schematic (part no. 30010421-02) page 5, there are 3 flash memory (two AT45DB321D and one S25FL032P0) and each of them is 32Mb (4M bytes). Why there are three 4M bytes flash being used?

In the case of the RCM6700, it uses a SPI interface to a serial boot flash to copy code into RAM for execution, so everything goes into RAM. Some products with a parallel flash execute code from that flash, others start booting from that flash but copy code to RAM for faster execution (since RAM requires fewer wait states).

The Rabbit 6000 includes 1MB of in-chip RAM, plus 32KB of battery-backed in-chip RAM. The RCM6750/RCM6760 add an additional 1MB external RAM.

The “root” space limit is due to 16-bit pointers only addressing 64KB. Separate Instruction & Data space allows for doubling up some of that space depending on the opcode used to access it.

I believe the compiler automatically splits available XMEM between code and data as needed, so “XMEM variables” end up in unused “XMEM code” space, and xalloc() can allocate memory at run-time from that unused space.

Bottom line: you need to update your program to move root variables and/or constants to xmem. Look at your map file to identify the largest (likely buffers or large arrays) and try moving those first.

They’re just different footprint/chip options for the 1MB or 4MB serial boot flash used on the RCM67xx board. Only one will be populated on a given build.