I have a piece of code that writes to a global floating point variable that is stored in a particular memory address. The variable is initialized to zero. The program I am writing is still in development, so the code that writes to the variable is
global_var += 0 * function(local_var);
I.e. The code increments the variable by zero every loop. There is no other code that writes to this variable.
However, this variable changes to a random number at random intervals. This leads me to believe that I have a memory issue elsewhere in my program; one that is unintentionally writing to that memory address.
I have used stack-painting to check that this is not a stack overflow issue. Also I think it would be noticeable if the stack was overflowing onto the global data (it is a single address that is being overwritten, not an entire region of memory).
I have used the watchpoint tool in Kinetis Design Studio to have the program break whenever the variable is written to. This was not useful here as the variable is constantly being written to its previous value. I tried to use the "Condition" field when setting the watchpoint, however I was unable to find any documentation on how to use the feature, and the KDS release notes say that conditional breakpoints don't work anyway.
I have also tried changing the code so that it is not constantly being written to by my line of code so I could use a watchpoint. However, this slightly changes the program structure, causing the memory issue to move to a different area of memory. As such, it becomes much more difficult to find.
Are there any tools or methods that I could use that I am missing here? Changing the code causes the issue to be moved to a different area of memory, so it appears that poor-mans debugging is out of the question.
If you are sure it is not a stack overflow take a look in your map file for the location of this variable. Then check which variable is just below it.
If this is an array (often the case) it will be that you are writing over the end of this array and thus corrupting this variable. Once you see the array name you can check the code and it may become obvious.
Thank you for the suggestion. I forgot to mention that I have already checked the variables which are nearby in memory (using the memory monitor and the .map file generated by the linker), and unfortunately none of them are arrays. The nearby variables are instead variables that would cause noticeable side effects if they were being overwritten.
If it is not stack and not an array overflow think about possible DMA transfers. I have experienced memory corruption due to a DMA transfer not terminating as expected, which debuggers won't be able to trigger on. (Or you have a peripheral that is being pointed to this location by mistake).
Pause the operation and check all DMA channels to see whether one has an unexpected destination pointer value.
P.S. If you don't make progress and it is a project that has commercial consequences I can help with debugging. I have (many) years of such fault finding experience for customers in > 30 countries so can usually solve it in a short time (by remote desk-top).