0

I am currently working on a Freescale Vybrid (VF6xx) MCU, trying to configure an external LPDDR2 DRAM chip.

I am experiencing some odd behavior from the DRAM (memory mapped to 0x8000_0000): When stopped at a breakpoint, the DRAM still seem to change every time i read from it in the debugger.

ARM DS-5 memory view of DRAM, refreshing at 1s intervals.

Does anyone know what might cause this?

Cheers!

Tom
  • 414
  • 4
  • 17
  • I believe the 6xx series is the Cortex-A5+Cortex-M4 one, so you've got two completely independent CPUs, plus many DMA-capable peripherals in that thing - any number of things could be carrying on whilst one of the CPUs is stopped (and still even if both are). It could even feasibly be the DRAM controller itself if it's got some kind of MBIST routine. Without a lot more information I doubt anyone can say for sure. – Notlikethat Dec 01 '15 at 15:07
  • I would examine IRAM and see if it is the same. Do you have cache enabled? It looks like an addressing error. I see the values moving towards low memory. Ie 'w.zo' (ascii to right) moves up the screen. No one can answer this question without more details. It is probably a hardware issue or the LPDDR2 configuration. See Freescale app notes (on VF6xx DDR) and [ARM memtest question](http://stackoverflow.com/questions/11640062/how-to-do-memory-test-on-arm-architecture-hardware-something-like-memtest86) – artless noise Dec 01 '15 at 15:54
  • @Notlikethat The secondary core (M4) is disabled. There should be nothing but the main MCU that interacts with the DRAM. We are assuming that the issue is with how the memory controller is configured. Hence we are looking for common issues that might cause the symptoms we are experiencing. – Tom Dec 02 '15 at 07:30
  • @artlessnoise The IRAM is not exhibiting the same behavior, and the cache is disabled. An addressing error should not cause the DRAM to change when the MCU is stopped as repeated reads at the same address should return the same value. A write-then-read procedure (using volatile pointers of course), does not return the value written. The same procedure run a few thousand times (0x0,.., 0xffff sweeps and random patterns) shows that the read value from the DRAM is unaffected by the value being written. – Tom Dec 02 '15 at 07:38
  • So, that is a lot of information I would have to guess to answer your question. How can anyone (including you) know this is not a hardware issue? Then, how is this a suitable question for SO? The other question gives some ways in software to see if there are hw issues. You need to use a scope/logic analyser and see if the signals have good integrity. Follow the appnotes and read/re-read both the LPDDR, vybrid controller and download the JEDEC specs on LPDDR. Often the controller or chip documents assume you have intimate understanding of the JEDEC spec. – artless noise Dec 03 '15 at 14:08
  • 1
    Check out http://electronics.stackexchange.com/questions/tagged/ddr3 and other tags. If the address lines are flakey, you will always read/write to some unknown location. Your write may have succeeded to some unknown location; maybe you can never read from that location. Different RAM test are developed to try to diagnose different issues. The signals are 'control', 'data' and 'address'; control are most critical with data also having tight timing. Address is the least critical. Of course all of them can be flakey. Try a minimum clock rate first. – artless noise Dec 03 '15 at 14:14

1 Answers1

0

I eventually found an answer to the issue.

As it turned out, the DRAM setup defined wrong address pin. The manufacturer provided a recommended value for the register defining this bit, but this turned out to be wrong.

For future googlers: The Vybrid Reference Manual Revisions 7 & 8 recommends DDRMC_CR73[APREBIT]=0xA for both DDR3 and LPDDR2. This assigns DDR_A10/CA10 as the address pin. The JEDEC standard specifies DDR_A0/CA0 as the address pin, thus the correct value should be: DDRMC_CR73[APREBIT]=0x0.

Tom
  • 414
  • 4
  • 17