Resources | Resources |



Debugging random memory corruption

Random memory problems are the most difficult to solve. It is usually not difficult to identify a random crash, but can be difficult to determine who and when. There is no single tool that is best for locating the problem; the following can help identify the problem:

  • Using the Simulator may help by providing more debug information.
  • Improve code quality through static code analysis tools.
  • Use a write break point if there is a data corruption problem at a specific address.
  • Embedded trace macro call (ETM) is the most effective tool. The typical use of this tool for random memory corruption is to turn on data write tracing. When a crash occurs, Trace32 provides the exact memory address that is corrupted. Look at the instructions executed in the five seconds before the crash to locate where the memory address was written. With the instructions and context around this location, you should be able to determine the problem.