Hi,
I started an ATE implementation some months ago and until I reach half of available memory life was a breeze.
Exactly after 1/2 use of available memory Serial.print and Serial.println start to fail, failure modes are change of format or even message suppression.
Environment: processor is an ATmega168, intensive use of SPI for I/O expansion. Version 10 or 11 have the same bug.
Does anyone have any clue or hint? Thanks in advance,
Celso
Which kind of memory? Flash or RAM? How can you tell that you're only using half of it?
Mellis,
Thanks for your help.
It is the available flash memory. At the end of complation, there is a message: binary sketch size: XXXX bytes (of a 14336 byte maximum). Problems start exactly after 7168 bytes. Until 7167 the Serial.print functions behave ok and deterministically. After 7168 bytes of code several failures occur like: format change or even supression of lines. It seems that the rest of the software is working ok.
Thanks in advance,
Celso
I'll take a wild guess and say this is just a weird coincidence, and you are really seeing the result of running out of RAM.
-j
What a coincidence! And exactly at 50% available limit. I believe in witches!!
I've tried several times with different softwares and the behaviour is the same.
Any suggestion/hint/clue will be most wellcome.
Thanks in advance,
Celso
I would also guess that you're running out of RAM.
Can you make a simple program that exhibits the problem, perhaps by using PROGMEM to make a giant array in flash ? (I couldn't see the problem...)
I also believe that the original poster is running out of RAM. This same thing happened to me. When my project compiled to about 8700 bytes it would reset and display junk. It turned out that I had vastly over filled the RAM. The problem is that, by default, strings are sent to the unit in FLASH but immediately take up RAM as well. So it's really difficult to determine exactly when the strings will overflow RAM. I should note that this is true of any variable, not just strings. But strings are a quick way to fill things up.
The fix, as someone already mentioned, is to use PROGMEM strings and the appropriate functions to deal with PROGMEM variables.
OK, I'll try it.
Unfortunately, I'm away from the hardware and I'll have to wait until monday to test it.
If I got it right you're telling me that the print function throws the data into the UART fifo and it is destroying stack or variable area? This would be a runtime error, according o the symptoms, the problem looks like a compilation error.
But I'll test it. If the problem continues, I will take screenshots and so on. I am a newbie in Arduino, this is my very first project.
Thank you all so far...
Cheers,
Celso
The problem is that literals are always stored in RAM (unless you use PROGMEM.) So, it looks like the strings are being stored in flash when you use them in a program but in reality they are allocated within your 1024 bytes of RAM. This can quickly overflow the boundaries. Some of the RAM is allocated to stack and such and you can quite easily overwrite the stack and the rest of RAM with strings.
You can't exactly count on a runtime error. The most likely result of the memory corruption is weird behavior.
Also, keep in mind that you can't really directly use PROGMEM variables in most any function. The usual strategy is to transfer the PROGMEM variable to a buffer in order to use it.
Dear folks,
Sorry for my late reply. Yes, you were right, that was really a weird coincidence and I ran outta RAM at exactly 1/2 available flash crossing.
Now I believe in witches, fairies, gnomes and so on.
Thank you all. Cheers, Celso