Data in RAM of stm32h7 gets messed up

[ZY3]

I wrote a code for stm32h745, masking the M4 core, and debugged it for two weeks without any problems per se, but yesterday, I realized that I could download the code, but in debug, I noticed that the data in RAM changes, and I didn't make any changes to that data, and I didn't have this problem before. My code hardly changes at all and I can rule out the out of address range issue. What is the reason for this. Is there any part of the chip that is damaged?

[Uwe Bonnes]

There are zillions of options, e.g.

unstable supplies, unconnected supply pins, missing decoupling capacitors, your program going amok, the debugger set up to use RTT, etc.

[Pavel A.]

DMA?

[bramble]

First thing to check is your stack allocation. A stack overflow call cause weirdly variable problems. 

Suspect the hardware as a last resort after you've checked everything else... it's almost certainly a software problem.

Somebody else mentioned DMA which you can check by disabling any peripherals that you may have configured to use it, and/or any DMA transfers in your application.

After that, you need to stare long and hard at anywhere you're writing to an array or raw pointer. You can also declare a dummy guard variable before and after any arrays, whether they're statically declared or malloc'd, write a magic value into them such as 0x12345678 then sprinkle in your code some checks to detect any unexpected change of those values.