I am having some issues trying to debug what appear to be some very strange behaviors. For example, we have:
static const char* LOG_FORMAT = "0x%02x,%.5f,";
and the pointer changes for no obvious reason. Sometimes to garbage, sometimes to other constant strings (or part of) defined elsewhere in the code. We also occasionally see the code jump to a different section which should not be running (State variable appears to change without being asked to). There are 2 or 3 common failure modes, and they appear to happen at random. It is a relatively large code base and adding or removing some sections changes the failure behavior (or removes it completely) even though those sections are NEVER referenced.
The best theory at the moment is that it is a memory related issue as we have been over all of the recent changes with a fine tooth comb, and the simple act of inserting sections of code to move things around appears to change or remove the behavior.
What are the best ways about debugging this issue or similar issues? Have found the debugger useful at times, and not at others (but that could be user error).
Further notes. ARM7, using Keil µVision 4 and the armcc v4.1 compiler.
Hi Stephen, with const char* you imply that the content of LOG_FORMAT is not mutable whereas the pointer to the location in memory can be changed (ref. https://stackoverflow.com/questions/9834067/difference-between-char-and-const-char ). It's difficult to tell exactly what's happening here without some more information on the code: is LOG_FORMAT declared within a function or as a global variable? The behaviour is different in the two cases.
It would be REALLY useful if you can extract a code snippet which shows the behaviour so that it can be reproduced. Did you try to use newer versions of Arm Compiler such as version 5.06? It can be downloaded here: https://developer.arm.com/products/software-development-tools/compilers/arm-compiler/downloads/version-5
Debugging intermittent problems can be hard indeed. One possible way is to use data watchpoint or trace. In the past I came across similar issues because interrupts were updating global variables not declared as volatile, it might be worth checking that.
Hope this helps.
Stefano