Variables starting to over-write each other

Hello I have a Mega2560p, with a pretty in-depth and long program onboard. The code all works.... except I am finding that random variables are starting to be overwritten (falses becoming true). Its not the code. I have followed the code, and added shortcuts and I think it was the last SD card text retrieval routine that has started to mess things up.

I have included just the declared variables here that I think are the culprit. There are a LOT of variables in this code. Memory is at 60% I think, and prog at 72%... If I remember rightly. Not maxed out by any means. I moved all my LCD text to ProgMem and that helped greatly early on in the coding.

One of the last variables I declared was 'char Ins_text[40];' I am suspecting this. Where would it write these variables, and can I tell it where to begin writing them? Also, is there any way of knowing what addresses are free?

Any direction greatly appreciated. The code is SO long and SO messy, I seriously doubt you need to see it for this particular question

char Ins_text[40];                       //Instructions text line
byte Datapage;                           //What page of instructions are being displayed
byte text_line;
byte DataNo;                             //Number of data files for information

It IS the code, specifically YOUR code! You are surely writing past the end of an array, writing using an invalid pointer, or something similar. Variables do not, CAN not, "over-write each other". Only the programmer can make that happen.

Regards, Ray L.

Keep in mind that the flash and SRAM numbers you see at the end of a compile are static numbers, not what happens at runtime. You probably have plenty of flash memory; it's the SRAM that's usually the issue. You have 8K of SRAM. The data you have defined globally sit at the bottom of this 8K (in a chunk often called the heap). Each time you call a function, any parameters used by the function, plus some overhead data, are pushed onto a SRAM section called the stack, which starts at the top of the SRAM and grows downward as you use it. So, the heap is at the bottom and, as your program runs, the stack grows downward towards the heap. If you have recursive function calls, or a lot of function calls within function calls, it's possible for the stack to collide with the heap. If that happens, all bets are off.

I've had stack collisions with the static SRAM stats at 71%. My guess is that your global data definitions are not the problem, but the function calls are.

Well I realise that it is my code... but it's not a problem I have deliberately created by defining something twice or similar. It's a problem where something is colliding or conflicting with something else.

A stack collision is possible then. Especially as I am in the 70%+ ballpark

I did manage to get a full .txt download of all the memory being used from the command prompt using Objdump.exe. Can't say it helped however!

I have 106 x 16 character LCD messages defined in Progmem, and somewhere around 170 defined variables within which there are probably 40x Longs, plenty of Ints and a ton of bytes! I have been through them to ensure they are the correctly defined type of variable (no wasted space)

Post the code (attach if it exceeds 9000 characters).

People will only be able to guess without it.


I am not using that many of the pins on the Mega.
I think I may add a 512k SRAM chip to help the situation anyway. Just found a 5v version so no level shifting

Arduino_Steve: I think I may add a 512k SRAM chip to help the situation anyway.

I doubt that this would help.

Whithout seeing all of your code I guess that you write outside an array.

Yes. I will check that I am not writing outside my arrays. Don’t think I am (I have written checks into the code), but I am only human.

The code is on my laptop in the garage - will lift it off later

Arduino_Steve: I think I may add a 512k SRAM chip to help the situation anyway. Just found a 5v version so no level shifting

I'm struggling to understand how that is going to help. How are you going to connect it? As far as I know, the board (or even the chip) doesn't bring out the processor's address / data busses. Do you intend to bit-bang those? No way that could substitute for processor RAM. Think the best plan is to fix your code.

ATmega2560 can use external SRAM and access it just like internal SRAM (but slower) – see section 9 in the datasheet.

Thanks. Good to learn something.

OK sorted. Added external 23lc512 SRAM this afternoon (found one on an old project board). Connected using SPI.

Shovelled a pile of my variables over to it and that seems to have cured the issue, as my 2560 memory usage has significantly dropped.