Hi Folks,
My Mega2560 is frustrating me totally at the moment. When loading a program, the IDE appears to negotiate the upload and then the progress bar halts about 4/5's of the way across and stops there. The Serial LED's continue to flash but nothing more happens, the IDE just waits and waits.
The program is about 27kb and using a simple memory determining tool
// free RAM check for debugging.
int availableMemory() {
// Use 8192 with Mega 2560 8k SRAM
int size = 8192;
byte *buf;
while ((buf = (byte *) malloc(--size)) == NULL);
free(buf);
return size;
}
it says I have 4040bytes of memory free, the program then connects an XMem memory expansion board
void setup() {
Serial.begin(115200); //Serial interface for Debugging
Serial.println("?? MIDI ?? Begins.. ");
Serial2.begin(31250); //set up Serial Interface 2 for Midi (Mega Pin16 Tx2)
Serial.println(availableMemory()); //returns 4040
xmem::begin(true); // use the memory in bank zero, with LowMem Stack,Heap etc
xmem::setMemoryBank(0, true); //manually select memory bank 0.
midiFile = reinterpret_cast<byte *>(0x2200);
Serial.println(availableMemory()); //returns 8191
that increases SRAM to 64kb and accordingly the checking the memory available after this says 8191bytes are free (it is a simple tool after all).
However if I add this routine
void updateNo(int nos, int line){ //Write a number into the LCD screen in ASCII from 15-18 characters across
if(nos<0 || nos >999){//it won't render Negatives or numbers >999
lcdLine("Out of Range!!!!", YELLOW, 16);
}
}
near the end of the program with a simple IF statement in it, the IDE upload just stalls. (I plan to extend the routine to turn a int variable into a sequence of ASCII Numerals on an LCD screen. Little point at the moment.)
When I remove the above routine, and maybe add other routines, eg the memory checker above, it does not miss a beat.
My first thought was it was running out of memory somehow, but I think I have covered that. My second thought was a "loose cannon" pointer somewhere blasting holes in the data structures, but the program does not actually begin to run so while I can't say definitely haven't got bytes corrupting the program, that does not seem to be a problem either (as yet). The program minus the additional code above appears to behave as predicted and quite stable. Grrrrr!
If anyone has some helpful suggestions how I can debug this, I would be very appreciative.
Cheers, Rob