AnsweredAssumed Answered

Strange behavior testing DDR2 in ADSP-21469 custom board

Question asked by yanava on Sep 13, 2011
Latest reply on Sep 15, 2011 by Mitesh

Hey guys, I'm testing the the connection between the DDR2 and the ADSP-21469 in a board I designed. I followed the rules you guys pointed out in one of your EEs. It took me a lot of time and effort to do it, but I am not sure the layout can be ruled out as a possible candidate for what's happening.

 

The only mistake I'm definately sure I made is connecting two devices to the same bank, one to the AMI (a W5100, that works perfectly) and one to the DDR2 controller (a DDR2 chip in an FBGA84 package). This mistake was already discussed previously in another discussion and the conclusion was that I would have to use the devices alternatively, not simultaneously. This is not an issue now.

 

I have a SHARC EZ board here that carries the MT47H64M16 chip. I planned to use the same guy in my design, and followed the same schematics ADI did. Unfortunately, it was non stock and I was in a hurry, so I sacrificed a little mem space and used the MT47H32M16 instead. It has the same pin config and same performance figures as the 1Gbit chip, just smaller capacity.

 

I wrote the simple program below to test DDR2 functionality in my custom board. I'm using the USB-ICE to debug the application. I made absolutely no further configurations and modifications to this code.

 

 

/*****************************************************************************
* DDR2Test.c
*****************************************************************************/
#include<def21469.h>
#include<Cdef21469.h>
#define SIZE 256
#pragma section ("seg_sdram")
int data[SIZE];
#pragma section ("seg_pmco")
int main( )
{
int i = 0;
for(i=0;i<SIZE;i++)
{
   data[i] = i; 
}
 
return 0;
}

 

 

The first thing I notice is that the data path is right. If write 0xABCD1234 to the chip, I can read it back, so data lines are okay, as far as I'm concerned.

 

Well, let me guide you to what the data looks like as the for loop progresses. The linker put that data array on address 0x900000, but if I put it on 0x200000 using pointers it exhibits the same behavior.

 

1st iteration - it writes 0x00000000 to position 0x0.

2nd iteration - it writes 0x00000001 to position 0x1.

3rd iteration - it writes 0x00000002 to positions 0x2, 0x4 and 0x6.

4th iteration - it writes 0x00000003 to positions 0x3, 0x5 and 0x7.

5th iteration - it writes 0x00000004 to positions 0x2, 0x4 and 0x6.

6th iteration - it writes 0x00000005 to positions 0x3, 0x5 and 0x7.

7th iteration - it writes 0x00000006 to positions 0x2, 0x4 and 0x6.

8th iteration - it writes 0x00000007 to positions 0x3, 0x5 and 0x7.

9th iteration - it writes 0x00000008 to position 0x8.

10th iteration - it writes 0x00000009 to position 0x9.

11th iteration - it writes 0x0000000A to positions 0xA, 0xC and 0xE.

12th iteration - it writes 0x0000000B to positions 0xB, 0xD and 0xF.

13th iteration - it writes 0x0000000C to positions 0xA, 0xC and 0xE.

14th iteration - it writes 0x0000000D to positions 0xB, 0xD and 0xF.

15th iteration - it writes 0x0000000E to positions 0xA, 0xC and 0xE.

16th iteration - it writes 0x0000000F to positions 0xB, 0xD and 0xF.

17th iteration - it writes 0x00000010 to position   0x10.

 

Well, rinse and repeat. I tried the DDR2 configurator to slow down the clocks and parameters, so timing wouldn't be an issue anymore. It makes absolutely no difference. I'm inclined to think this is an address space problem and that a solution is possible. Is there anything to do with me using another chip?

 

I will try to probe the system with a 1GHz scope to see if theres anything that looks bizarre. The fact that the data lines work and the address is going apeshit is quite strange. Everything was matched to be have a length difference of less than 100mil (90mil was the goal).

 

Thanks in advance.

Outcomes