I have been experiencing resets or SPI failures or just otherwise strange behavior that I would attribute to memory issues.
Unfortunately, I'm unsure exactly what part of my program is doing this. Due to the nature of the issue, randomly adding/subtracting code will change the results I see regardless of how inert that code is. It makes it difficult to debug this.
I don't believe the issue has to do with a stack overflow because I am using an Arduino Mega and my test program uses 5%/7% storage. Rather, I think these issues are just invalid memory writes/reads that cause undefined things to happen.
I've narrowed it down to a chunk of code that looks to be doing nothing of use since it's just an agglomeration of potential problem bits. If anyone can help narrow this down further within that piece, it would be useful.
Attached is a sample program which uses the ILI9341 and XPT touchscreen on a mega. It's a lot of boilerplate mostly, down at the bottom is the function doSomethingObscure which seems to cause the problem though (when doSomethingObscure() is called, the board resets currently).
Any thoughts on what could be the problem in doSomethingObscure()?
You will get answers faster if you post your code in accordance with the forum guidelines in the "how to use this forum-please" read stickies.
I would put some prints in to keep an eye on array indexes. The reported issue is often a symptom of writing past the end of an array into memory that you do not "own".
Another technique that sometimes works for problems like this is to binary chop the suspect function using comments or #if 0..endif to isolate the problem.
This doesn't always work because of compiler optimisation, but it is reasonably quick to try.
groundFungus:
You will get answers faster if you post your code in accordance with the forum guidelines in the "how to use this forum-please" read stickies.
I would put some prints in to keep an eye on array indexes. The reported issue is often a symptom of writing past the end of an array into memory that you do not "own".
Unfortunately the code was too large to inline.
TolpuddleSartre:
Another technique that sometimes works for problems like this is to binary chop the suspect function using comments or #if 0..endif to isolate the problem.
This doesn't always work because of compiler optimisation, but it is reasonably quick to try.
I've found with this issue that changing around the structure of the code (and therefore what memory ends up looking like) affects the undefined behavior, sometimes causing everything to work, even. So inconsistent results when adding/removing segments of code made this hard to pinpoint.
westfw:
That looks pretty suspicious. I don't see any encodingNames that have a length even close to 13.
(it's also really hard to read. Consider using some intermediate variables to make the logic more visible.)
PaulMurrayCbr:
paddedStr has a size of 9, but your calls to padLeftWithChar pad out to 13. Make paddedStr bigger - at least 14.
Good catch, that looks like it was the fix! Applying it back to my entire codebase, I seem to still be having SPI failures, so there's probably another issue somewhere else. Maybe I'll try to capture the problem in a sample again - I'll post another similar file if I end up getting stuck with another needle-in-a-haystack problem.
The solution to "needle in a haystack" problems is to make the needles bigger, and the haystacks smaller.
That way, you'll find the problems earlier during testing.
To mangle a metaphor, they'll stand out like a sore needle.