Problem of writing DDR3

Max,

I would be happy to help you root cause.

Can you send me the following:

1. the register and PHY calc spreadsheets filled out to match your initialization

2. A dump of the DDR controller registers before and after your run the test

Max Kovnerev said:

I change the bit (DDR_SDCFG - NM bit field 15:14) at 32x and 16x, respectively 

Assume you do this in the GEL file and re-run the initialization routine as opposed to changing the bits in real time?

How are you filling out the memory? Using the memory window or using the DSP?

Can you try writing to DDR with an EDMA burst of, say 256B and see if you face the issue?

Thank you, Aditya.

1. DDR register and PHY calc with my board dataspec.

2148.DDR3 Register Calc v4.xlsx

8130.DDR3 PHY Calc v10.xlsx

 My GEL file

5852.x_evmc6678l.gel

2. I fill with using the memory window in debug session.

I'm doing a re-initialization, when changing the bits.

- dump of the DDR controller before initialization

8182.pre_init.dat

- dump of the DDR controller after initialization

6507.post_init.dat

- dump of the DDR controller after filling data

6114.post_fill_data.dat

Max

Ilya,

Please keep the discussion iun the e2e forum.

Can you clarify a few things:

1)      I assume they have a single prototype board, or are they seeing an issue on multiple proto boards?

2)      Does the behavior show dependency on DDR frequency , have they tried all frequencies

3)      Has it been confirmed that the schematic hook up for DDR memory is correct?

Max, Illya,

I have verified that the GEL files, register/PHY spreadsheets and register dumps all look expected..no flags there regarding pagesize/columnsize etc.From a s/w standpoint we should be fine.

You observe this behavior on specific addresses. That likely points to the schematic hookup as Tom mentioned in #3.

I mapped the address bits for each bus width to help with this process. On each case, logical address bits 3 and 4 are always found in the problem addresses. Let us know what you find.

'x' - dont care

64-bit:
Problem addresses:
0x80000038 = 0x8000 0000 0000 0011 1xxx
0x80000039 = 0x8000 0000 0000 0011 1xxx
0x8000003A = 0x8000 0000 0000 0011 1xxx
0x8000003B = 0x8000 0000 0000 0011 1xxx
0x8000003C = 0x8000 0000 0000 0011 1xxx
0x8000003D = 0x8000 0000 0000 0011 1xxx
0x8000003E = 0x8000 0000 0000 0011 1xxx
0x8000003F = 0x8000 0000 0000 0011 1xxx

Good addresses:
0x80000040 = 0x8000 0000 0000 0100 0xxx

32-bit:
Problem addresses:
0x80000018 = 0x8000 0000 0000 0001 10xx
0x80000019 = 0x8000 0000 0000 0001 10xx
0x8000001A = 0x8000 0000 0000 0001 10xx
0x8000001B = 0x8000 0000 0000 0001 10xx
0x8000001C = 0x8000 0000 0000 0001 11xx

Good addresses:
0x80000020 = 0x8000 0000 0000 0010 00xx

16-bit:
Problem addresses:
0x8000001E = 0x8000 0000 0000 0001 111x
0x8000001F = 0x8000 0000 0000 0001 111x

Good addresses:
0x80000020 = 0x8000 0000 0000 0010 000x

Aditya

I found the following feature:

The following code is fully writes all memory:

void main()
{
    unsigned int *k = (unsigned int *) 0x80000000;
    unsigned int  x,p=0;
    *k=0;

    for (x=0;x<100;x++)
    {
        *k = 0x12345678;
        if (*k == 0x12345678)
        {
        p++;
        }
        k++;
    }
while (1);
}

If you remove the check after each recording, the behavior of a similar entry through the memory browser.

Do you have any ideas?

Regards, Max.

Max,

Max Kovnerev said:

If you remove the check after each recording, the behavior of a similar entry through the memory browser.

Not sure what this means. You mean if you remove the if statement inside the for loop, you see the gaps in the 2nd screenshot? Or does that happen when you enter the data through the memory browser?

Have you probed the DDR clock frequency to see if it is what you expect (~666MHz)?

Does this happen only at DDR3-1333 or have you tried other speed bins (DDR3-1066 or DDR3-800)?

Quoting Tom from an earlier update:

Tom Johnson16214 said:

1)      I assume they have a single prototype board, or are they seeing an issue on multiple proto boards?

2)      Does the behavior show dependency on DDR frequency , have they tried all frequencies

1. Yes,  2nd screen - after remove the if statement inside the for loop

2. Similar behavior at low frequencies (400MHz) and a change in the DDR3 registers at K4B4G1646B (800)

3. This is repeated on several boards.

Regards, Max

Aditya,

The issue is closed. there was a mistake in schematics: DQS_n and DQS_p pins were swopped.

BR,

Ilya

Ilya, thanks for confirming. Could you please mark the thread as resolved?