I haven’t tried it with Arduino but something I’ve done with other systems is add a small piece of code at the start of the program that fills the stack and heap areas with a simple pattern, such as all 0xFF or all 0x55 or incrementing values 0x01, 0x02, 0x03, …
You then use your program as usual and then at some point dump the stack/heap area and look for the area(s) where the pattern has been overwritten.
With the Arduboy you could use the global variable use reported after a compile to calculate the area to be filled with the pattern. The code to set the pattern would go at the very start of setup().
Assuming resetting to the bootloader doesn’t clear the RAM, you could press the reset button and then use avrdude to dump and examine the RAM.
Interesting … my only concern with this is that I then need to include the serial.print code into the sketch. I guess that’s predominately PROGMEM so it shouldn’t affect the RAM readings. I did have an issue where I could not connect via the serial monitor - probably for the exact same reason I couln’t flash the board without intervention.
@MLXXXp’s solution is probably more appropriate if you cannot connect the serial monitor.
Actually, I could use the freeMemory routine and write it to the the eeprom for later retrieval. Some sort of ‘if freeMemory() < last recorded value then update eeprom with freeMemory()’.
The problem with freeMemory() is that is just tells you the amount of free RAM at the point that it’s called. If you want to know the maximum amount of dynamic RAM ever used by the program, you would have to call freeMemory() at the point in the program where this maximum use occurs. This point may be difficult to determine with a complex program. And, it might occur during execution of a function in an external library that you aren’t intimately familiar with and/or don’t want to “patch” with freeMemory() calls.
With my method, you don’t have to worry about this. You just use the program normally, hopefully at some point executing the code that will use the most dynamic RAM. Then sometime later you examine the RAM to see how much of it has been “clobbered” based on the amount of the pre-set pattern that has been disrupted.
What problem? The need to use flashlight mode to load another sketch?
First, I’d rule out it being a global variable that’s causing it. For this, I use objdump to find out what, if any, global variable has the same address as the bootloader “magic key”.
If instead it turns out to be a local variable or the stack, then yes, it could be difficult to find.
In any case, it’s not really worth trying to fix because any later changes to your code or the libraries that you use, or even the compiler itself, could alter the memory layout and cause the problem to reoccur.
Yes … I really meant what library call or stack issue is causing the problem.
True. But if it is ever ‘finalised’ (when is a game ever finished?) then you can thump out a HEX with the problem gone. If you recompile it after this, you may introduce new issues due to library updates and the like.
ProjectABE shows the global variable RAM usage but doesn’t show you at runtime the dynamically allocated RAM and stack use. I just spoke to @FManga and he is going to look at whether this might be possible but he is concerned about the performance problems it might create
@filmote - After downloading from GitHub and uploading with Arduino IDE I get this error:
In file included from sketch/src/Entities/Entities.h:4:0,
sketch/src/Entities/Level.h:9:25: fatal error: FixedPoints.h: No such file or directory
exit status 1
Error compiling for board Arduino Leonardo.
I looked through the files in the repository and that FixedPoints.h file is indeed missing. I might be missing something, but I wanted to let you know just in case it’s legit.