I have a problem that cannot exist. I keep building programs in MPLab that are close or just over my allotted RAM. I really want to see by how much over my RAM ("data memory" - why do they use such an obscure name) I am.

All the optimizing tools fail, again without telling me how much my allotted RAM they are over by. So if they're all failing, what use is this tool? It should say how close each optimizer came to fitting in the allotted RAM.

It seems like an extremely important and obvious feature to have, when building on a computer with gigabytes and gigabytes of RAM to simulate with.

Here is the output from PIC10F220:

Non line specific message::: error: (1359) no space for ___ftmul parameters
(908) exit status = 1
make[2]: Leaving directory '/Users/kmizzle/MPLABXProjects/Pic10.X'
make[1]: Leaving directory '/Users/kmizzle/MPLABXProjects/Pic10.X'
make[2]: *** [nbproject/Makefile-Config_C.mk:171: dist/Config_C/production/Pic10.X.production.hex] Error 1
make[1]: *** [nbproject/Makefile-Config_C.mk:91: .build-conf] Error 2
make: *** [nbproject/Makefile-impl.mk:39: .build-impl] Error 2

There are always random issues such as:

  • Assigning a bigger value to an existing variable. Even though it's still 8-bit, the multiplication of a constant by an 8-bit variable causes an out-of-memory error.
  • "Delaying" for a variable amount of time. __delay_ms(x) does not work, but __delay_ms(10) does work. -- WHY??
  • It's probably too much to ask, but as I declare local variables and such, the total RAM used will change. It would be extremely useful to know when, within the program, the RAM was overflown as well.
  • I will add more here if I think of them

The problem is that it would be a lot easier to figure out what was happening (is it casting to an int? why?) if I could see exactly how much over the memories that I was.

  • 1
    \$\begingroup\$ MPLAB, or MPLABX? \$\endgroup\$
    – rdtsc
    Aug 25, 2022 at 18:16
  • \$\begingroup\$ MPLABX. So you can't even tell whether it's going over program memory or data memory? \$\endgroup\$
    – Mr Man
    Aug 25, 2022 at 21:07
  • 1
    \$\begingroup\$ @MrMan - Hi, Thanks for trying to help by adding info. However: (a) Please stop adding new points into the question. Otherwise it might be closed as "needs focus" aka "too broad". To be safe, only ask about one issue per question, unless you are very sure they have the same cause. (b) The function name mentioned in the error message implies you're trying to use floating-point maths. On a PIC10. That's a concern! Suggest you add full source code, so readers can better understand what you are trying to do. \$\endgroup\$
    – SamGibson
    Aug 26, 2022 at 11:59
  • \$\begingroup\$ Could always look into other technologies and IDEs. Perhaps CubeIDE will suit you better. \$\endgroup\$
    – rdtsc
    Aug 26, 2022 at 12:06
  • 1
    \$\begingroup\$ One trick I've used is to simply select a larger chip with more memory from the same family (or as close as possible) temporarily in the project settings. Then, when the compilation does succeed, you can see in the report how much data memory is being used and you can calculate how much the original chip lacks. \$\endgroup\$ Aug 26, 2022 at 13:07

2 Answers 2


"Data memory" - why do they use such an obscure name?

To try to differentiate it from the many other types of memory:

"Memory", "RAM" = PC volatile storage (infinite cycles.)

"EPROM", "EEPROM", "Flash" = PC BIOS non-volatile storage (thousands of cycles.)

"Aux Flash", "Data EEPROM" = PIC non-volatile data storage (robust but small, withstands many cycles)

"Data" or "Data Memory" = PIC volatile RAM (infinite cycles)

"Program" or "Program Memory" = PIC non-volatile code storage (which happens to be flash, limited to thousands of cycles.)

[MPLABX] should say how close each optimizer came to fitting in the allotted RAM.

While under the limits imposed by the particular PIC being compiled for, it will report this information as a summary:

Memory Summary:
    Program space        used    BDh (   189) of  2000h words   (  2.3%)
    Data space           used    14h (    20) of   400h bytes   (  2.0%)
    EEPROM space         None available
    Configuration bits   used     5h (     5) of     5h words   (100.0%)
    ID Location space    used     4h (     4) of     4h bytes   (100.0%)

make[2]: Leaving directory 'C:/Users/me/foo/bar/ACTDSWT.X'
make[1]: Leaving directory 'C:/Users/me/foo/bar/ACTDSWT.X'

BUILD SUCCESSFUL (total time: 6s)

From this, I know that 0x14/0x400 data bytes are used or 2%, so 0x3EC remain.

Therefore, if I try to assign 0x400 more bytes, it will fail.

It can also report this in the dashboard as a visual "gauge": MPLABX reported program and data usage

But the moment program/data are exceeded, it fails to build with a message like:

"C:\Program Files\Microchip\xc8\v2.36\bin\xc8-cc.exe"  -mcpu=16F15375 -Wl,-Map=dist/default/production/ACTDSWT.X.production.map  -DXPRJ_default=default  -Wl,--defsym=__MPLAB_BUILD=1   -mdfp="C:/Users/me/.mchp_packs/Microchip/PIC16F1xxxx_DFP/1.13.178/xc8"  -fno-short-double -fno-short-float -O0 -fasmfile -maddrqual=ignore -mcodecov=ram -xassembler-with-cpp -mwarn=-3 -Wa,-a -msummary=-psect,-class,+mem,-hex,-file  -ginhx32 -Wl,--data-init -mno-keep-startup -mno-osccal -mno-resetbits -mno-save-resetbits -mno-download -mno-stackcall -mdefault-config-bits -std=c99 -gdwarf-3 -mstack=compiled:auto:auto      -Wl,--memorysummary,dist/default/production/memoryfile.xml -o dist/default/production/ACTDSWT.X.production.elf  build/default/production/mcc_generated_files/device_config.p1 build/default/production/mcc_generated_files/mcc.p1 build/default/production/mcc_generated_files/pin_manager.p1 build/default/production/main.p1     
main.c:33:: error: (1250) could not find space (400 bytes) for variable _baz
main.c:33:: warning: (1262) object "_baz" lies outside available data space
(908) exit status = 1
nbproject/Makefile-default.mk:186: recipe for target 'dist/default/production/ACTDSWT.X.production.hex' failed
make[2]: Leaving directory 'C:/Users/me/foo/bar/ACTDSWT.X'
nbproject/Makefile-default.mk:91: recipe for target '.build-conf' failed
make[1]: Leaving directory 'C:/Users/me/foo/bar/ACTDSWT.X'
nbproject/Makefile-impl.mk:39: recipe for target '.build-impl' failed
make[2]: *** [dist/default/production/ACTDSWT.X.production.hex] Error 1
make[1]: *** [.build-conf] Error 2
make: *** [.build-impl] Error 2

BUILD FAILED (exit value 2, total time: 2s)

From this message, we can tell that "baz" was supposed to be 400 bytes and could not be allocated. The only solution in this case is to comment-out or temporarily reduce "baz" and recompile until it succeeds.

Paid editions of the XC compiler should yield noticeable optimization savings, mostly in program size. But that won't help if trying to allocate a 1M buffer on a 1k chip, for instance.

Figure out how much data memory you need, then select a chip with more than that. Preferably twice as much, so there will be room to grow if the code changes during development, which it usually does. And is all that data memory really needed? Is it a mistake in defining the variable; i.e. should var[20]=0 really be var=20? Can it be simplified in some other way? Some PICs include provisions for connecting external data RAM chips. While complex, that is another possibility.

Note that when starting out, it is better to obtain smaller PICs first and work on small projects and slowly graduate to bigger projects. Because jumping into the complexity of bigger chips (with large memories) blindly can be astounding. This has caused some percentage of people to simply walk away from them in frustration. So do not let a large data requirement force you into using some big, overly-complex device if uncomfortable.

  • 1
    \$\begingroup\$ This did not answer the question. \$\endgroup\$
    – Mr Man
    Aug 25, 2022 at 21:08
  • 1
    \$\begingroup\$ Currently, there is no other answer. MPLABX currently does not tell you how much more data space you need when it is exceeded. \$\endgroup\$
    – rdtsc
    Aug 26, 2022 at 12:04
  • \$\begingroup\$ OT: 20 of 400 are 5%. Please consider the base, in this case hex: 0x400 = 1024, giving 20 of 1024 = 2%. The space left is 1004 bytes. \$\endgroup\$ Aug 26, 2022 at 12:50

AFAIUI, the XC8 optimizations don't affect data (RAM) memory usage, they're concerned with program (flash) memory.

You're pretty much in 100% control of the data memory usage, depending on how and where you declare variables and so on.

You can always reduce the size of an array or whatever and compile to see if that brings you back under the available limit, you don't have to run it.

If you're constantly running close to the limit (more than 60 or 70%), it's usually better to move up to the next larger chip (which typically does something like doubling the RAM).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.