uncontrolled SDRAM content change

Test# 1 looks wrong, if you write pattern1 to the memory then you should be validating if pattern1 is read back correctly and not pattern2 (I wouldn't expect a memory problem to cause pattern1 to magically become switched to pattern2). I was suggesting triggering on the writes to memory and not the data because after all it's the data you are seeing a problem with so you should be determining if the writes/reads are even reaching the memory.

Given your triggers I would assume the memory is really corrupt early in the test. Now if you trigger off the conditions I suggested at least you'll be able to verify whether the corruption occurs between the processor and SDRAM controller, or it the problem is in the SDRAM controller/interface/device. I suspect it'll be the latter which could suggest wiring/timing problem. I also recommend performing standard tests for things like stuck address/data lines, the memtest example software includes such tests. For example if you were looking for stuck data lines you would write walking ones/zeros to a fixed address to ensure only a single 1/0 walks across the word.