Is there a 128k limit on Mega 2560?

Hi,

I've been working a project for several months now, and as with all projects it's been slowing evolving and growing as I seek to improve it. (I'm using an Mega 2560 with version 1.0 software)

Recently, the project has stopped working, it still compiles and uploads, but when I run it I get a seemingly random string of numerals, and nothing else.....

10111411411111458329997114100461051101051163210297105108101100 83683210111411411111458321,0

Various posts on this forum have suggested it may be to do with either the amount of PROGMEM being used, or location within memory that the PROGMEM is being written to. I've tried moving my PROGMEM to upper memory by swapping all my declarations from this....

const prog_char  ERR_INT_14[]   PROGMEM = "*** Checking incoming SMSs ***";

to this....

const char ERR_INT_14[]   __attribute__((secTion(".fini7"))) = "*** Checking incoming SMSs ***";

But this made no difference.

I've recently noticed that my code has recently started compiling to greater than 128k...

Binary sketch size: 128414 bytes (of a 258048 byte maximum)

I've noticed a couple of posts mentioning a '64k limit' on some microprocessors (not sure what this actually means), I'm wondering if there is maybe a related 128k limit on the Mega?

I'm in the process of trying to shoe-horn my project to below this value to test my theory, but in the meantime any suggestions would be appreciated, even if only to tell me I'm barking up the wrong tree!

Also, if you have successfully worked with projects on the Mega that are greater than 128k please let me know - this will at least let me know if it's possible!

(not sure if this is relevant, but I have a total of about 800 PROGMEM declarations, each about 30-40 characters which total about 28k of PROGMEM)

Cheers

How much RAM are you using?

How much RAM are you using?

I'm not 100% sure, because I don't know how to measure it accurately. The Mega 2560 has (i think) 8k of RAM. I call this function at the start of my project (not sure what it's doing, I cribbed it from somewhere on this forum)

// this function will return the number of bytes currently free in RAM
// written by David A. Mellis
// based on code by Rob Faludi http://www.faludi.com
int freeRam() 
{
  //int size = 1024; // Use 1034 with ATmega328
  //int size = 2048;  // Use 2048 with ATmega328 (Duemilanove)
  int size = 8192;  // Use 8192 with ATmega328
  byte *buf;

  while ((buf = (byte *) malloc(--size)) == NULL);

  free(buf);

  return size;
}

This indicates I have about 1400 bytes left.

I don't think this is a RAM related issue (but could be wrong). I use PROGMEM statements to help log messages and errors to the screen or a log file, the only changes I made before this issue occurred was to add more PROGMEM statements to log more errors/information to the log file.

const char ERR_INT_14[]   __attribute__((secTion(".fini7"))) = "*** Checking incoming SMSs ***";

Does section really have a capital T?

Does section really have a capital T?

No.

See this post http://forum.arduino.cc/index.php?topic=169781.0;

cheers

I've spent two days on this and finally have a fix! Boy, have I been barking up the wrong tree!

First a bit more background about my project, when I run it plugged into my computer, I get to see all the messages on the screen, but when I run it 'live' I don't have a screen. So I've written library that takes all messages and writes to both the screen and an SD card.

The long string of numerals shown in the original post is what gets returned from the Sd.h library if Sd2Card.init() fails to intialise. It's got nothing to do with char array overflows or where the compiler places PROGMEM stuff in memory.

So the reason my original project failed was a hardware fault in the SD card shield. And the reason I got identical messages when I tested the code on other Megas is that they didn't have SD shields on them, I'd forgotten just how tightly bound my project was to the SD card library.

When I originally started my project, the SD card stuff was bound up in several libraries.... Sd2Card.h, FatStructs.h, Sd2PinMap.h, SdFat.h, SdFatmainpage.h, SdFatUtil.h, SdInfo.h. Several versions ago these where all wrapped up in a single library SD.h that came built in. what I didn't appreciate at the time, was that the original set of functions did at least return a brief but meaningful message ("SDinitfail" or something similar) which would prompt me to insert an SD card or get out my soldering iron.

Sadly my C skills aren't good enough to allow me to understand exactly where in SD.h this message is coming from, or what it means.

When I originally started my project, the SD card stuff was bound up in several libraries.... Sd2Card.h, FatStructs.h, Sd2PinMap.h, SdFat.h, SdFatmainpage.h, SdFatUtil.h, SdInfo.h. Several versions ago these where all wrapped up in a single library SD.h that came built in. what I didn't appreciate at the time, was that the original set of functions did at least return a brief but meaningful message ("SDinitfail" or something similar) which would prompt me to insert an SD card or get out my soldering iron.

Sadly my C skills aren't good enough to allow me to understand exactly where in SD.h this message is coming from, or what it means.

Perhaps you could ask fat16lib. He posts regularly, and wrote all the SD card stuff. The SD library now being delivered with the Arduino code is OLD. fat16lib's newer stuff is MUCH better, and looks more like the stuff you were originally using.