The AM3517 Wiki has a short note on how to configure VTP_DYNAMIC_UPDATE
It mentions that "it can lead to a more robust performance" for the DRAM interface.
In my book, this is the understatement of the year.
My newly developed prototype board has the industrial temp version of the AM3517 as well as Ind. Temp versions of Micron DDR2-800 RAM (512Mbytes, two chips, 16 bit each). Following the data sheet advice, I did not design in any termination resistors (which subsequently are noted in several posts are absolutely needed to get the temp range).
Without VTP_DYNAMIC_UPDATE I have similar issues, at even modestly low temps the RAM fails. However with VTP_DYNAMIC_UPDATE it is just fine.
But it does not stop here.
From my previous post you can see that I am questioning the internal design/setup of the data path from CPU to RAM (It is rather slow in cases of cache-miss read, my old ARM9 based Atmel system beats it by a factor of 2 with just 100Mhz SDRAM !!!!).
So I experimented and was rather surprised when I was able to raise the L3/L4 bus speed (Core clock). Not just a bit. In fact, I can go to over 600 Mhz (resulting in 300Mhz DDR clock) before it will quit somewhere between 600 and 700 Mhz. Note that the RAM still works perfectly at these speeds and seemingly at a reasonable temp range.
So I have now gone to a more conservative 400 Mhz core clock to leave some room for unknowns and it so far seems to work fine, including temps down to about -20 deg C (the lowest I can test here). So that means rather than a 166Mhz DDR clock I'm doing a more happy 200Mhz.
So, if you can - use VTP_DYNAMIC_UPDATE. It makes more than just a little difference, at least in my case.
Oh yes - I have also enabled half-termination on read (EMIF).
Rainier