SDRAM data shifts

lpcware · ‎06-15-2016

Content originally posted in LPCWare by wlamers on Thu Jun 20 13:16:44 MST 2013

During a read write test of a SDRAM I get some sort of bitshift of the data.

The SDRAM is a Micron MT48LC16M16A2 (16 bit wide).

Configured as (Row, Bank, Column): 256 Mb (16Mx16), 4 banks, row length = 13, column length = 9

If i write, for example, 0x1234ABCD in an array of length 1024 (or whatever, length does not matter) and I read those locations back I get this:

pos[0] = 0xABCD1234
pos[1] = 0xABCD1234
pos[2] = 0xABCD1234
pos[3] = 0x12341234
pos[4] = 0xABCD1234
pos[5] = 0xABCD1234
pos[6] = 0xABCD1234
pos[7] = 0x12341234
pos[8] = 0xABCD1234
pos[9] = 0xABCD1234
pos[10] = 0xABCD1234
pos[11] = 0x12341234

Note that every 4th location is different and all the others are shifted (as it appears).

Anybody a clue what is going on here? Has this something to do with the burst length maybe?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by wlamers on Fri Jun 21 05:33:44 MST 2013

Well I did some tests. First writing 0x1234ABCD + i (for loop sentinel, to mimick arbritrary data), then write 0xFFFFFFFF in a continious loop. I can configure the SDRAM up to 156 MHz succesfully (CPU clock also @ 156 MHz), or I configure the CPU at 204 MHz and the SDRAM at 102 MHz (and a CAS latency of 2 instead of 3) which yields the fastest speeds. This are the results with error checking (cost some additional CPU time):

--- SDRAM @ 102MHz, CPU @ 204 MHz, no compiler optimization
- write 0x1234ABCD: 25575 KiB/s
- read 0x1234ABCD: 18930 KiB/s
- write 0xFFFFFFFF: 28469 KiB/s
- read 0xFFFFFFFF: 21918 KiB/s

--- SDRAM @ 102MHz, CPU @ 204 MHz, with compiler (-O2) optimization
- write 0x1234ABCD: 132663 KiB/s
- read 0x1234ABCD: 33886 KiB/s
- write 0xFFFFFFFF: 132663 KiB/s
- read 0xFFFFFFFF: 39479 KiB/s

The compiler optimization seems to work well based on the write speed increase of a factor 5! Anyone seen this kind of difference before?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by wlamers on Fri Jun 21 04:53:13 MST 2013

I have found the error. I did some timing calculations wrong. These are the correct ones (works at 96 MHz):

LPC_SCU->EMCDELAYCLK = 0x00000000

    LPC_EMC->DYNAMICRP            = 1;
    LPC_EMC->DYNAMICRAS         = 4;
    LPC_EMC->DYNAMICSREX         = 6;
    LPC_EMC->DYNAMICAPR         = 0;
    LPC_EMC->DYNAMICDAL         = 4;
    LPC_EMC->DYNAMICWR            = 1;
    LPC_EMC->DYNAMICRC           = 5;
    LPC_EMC->DYNAMICRFC         = 5;
    LPC_EMC->DYNAMICXSR         = 6;
    LPC_EMC->DYNAMICRRD         = 1;
    LPC_EMC->DYNAMICMRD         = 1;

    uint32_t ModeRegister        = 0x33;                 // burst length 8, sequential mode, latency 3, standard operation mode, programmed burst length mode
    uint8_t Offset                 = 12;                     // 9 columns + 1 bus width + 2 bank select bits = 12
    *((volatile uint32_t *) (DynBaseAddr | (ModeRegister << Offset)));

LPC_EMC->DYNAMICREFRESH = 47;

lpcware · ‎06-15-2016

Content originally posted in LPCWare by wlamers on Fri Jun 21 02:13:05 MST 2013

Thanks for your information.

Unfortunately changing the EMCDELAYCLK (tried 0x0000 till 0x5555), or the clock frequency (tried 12 to 96 MHz) does not work. The latencies (3-3) are correct. Maybe I am doing something wrong in the other timings? These are the values @ 96 MHz:

LPC_SCU->EMCDELAYCLK = 0x00000000;

LPC_EMC->DYNAMICCONFIG2        = (0 << 14) | (13 << 7);    // 256Mbit(16Mb x 4 x 4 banks) in ROW BANK COLUMN mode (RBC), row len = 13, column len = 9         DYNAMICCONFIG2-> bit[14] = 0, bit[12:7] = 001101
LPC_EMC->DYNAMICRASCAS2        = 0x00000303;                 // Latency: RAS 3, CAS 3 CCLK cyc.

LPC_EMC->DYNAMICRP            = 1;
LPC_EMC->DYNAMICRAS         = 3;
LPC_EMC->DYNAMICSREX         = 6;
LPC_EMC->DYNAMICAPR         = 0;
LPC_EMC->DYNAMICDAL         = 5;
LPC_EMC->DYNAMICWR            = 1;
LPC_EMC->DYNAMICRC           = 5;
LPC_EMC->DYNAMICRFC         = 5;
LPC_EMC->DYNAMICXSR         = 6;
LPC_EMC->DYNAMICRRD         = 0;
LPC_EMC->DYNAMICMRD         = 0;

LPC_EMC->DYNAMICREFRESH = 110; // 110x16 EMC_CCLK's between refresh cycles.

And this is the burst length:

    uint32_t DynBaseAddr        = SDRAM_BASE_ADDR;
    uint32_t ModeRegister        = 0x23;                 // burst length 8, sequential mode, latency 2, standard operation mode, programmed burst length mode
    uint8_t Offset                 = 12;                     // 9 columns + 1 bus width + 2 bank select bits = 12
    *((volatile uint32_t *) (DynBaseAddr | (ModeRegister << Offset)));

Any idea?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by suckfish on Thu Jun 20 23:26:16 MST 2013

Could be a timing problem resulting in each 16-bit word getting delayed by a clock cycle? Try backing off all the timing parameters and/or the clock rate and see if that fixes things?

I have the same part on a board running fine. I did find that when I pushed the clock rates I had to back off one particular timing value from the data sheet values (I can't remember which, suspect it might have been DYNAMICDAL).

Also at higher clock rates you need to change EMCDELAYCLK (I have 0x0000 for up to 96MHz, 0x1111 for 97 to 129MHz and 0x2222 above that).

Double check that you have CAS/RAS latencies configured identically between the memory controller and the SDRAM chip.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by suckfish on Thu Jun 20 23:20:52 MST 2013
Could be a timing problem resulting in each 16-bit word getting delayed by a clock cycle?

Try backing off all the timing parameters and/or the clock rate and see if that fixes things?

I have the same part on a board running fine. I did find that when I pushed the clock rates I had to back off one particular timing value from the data sheet values (I can't remember which, suspect it might have been DYNAMICDAL).

Also at higher clock rates you need to change EMCDELAYCLK (I have 0x0000 for <= 96MHz, 0x1111 for 97 to 129MHz and 0x2222 above that).

Double check that you have CAS/RAS latencies configured identically between the memory controller and the SDRAM chip.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by suckfish on Thu Jun 20 23:14:38 MST 2013

Could be a timing problem resulting in each 16-bit word getting delayed by a clock cycle? Try backing off all the timing parameters and/or the clock rate and see if that fixes things?

I have the same part on a board running fine. I did find that when I pushed the clock rates I had to back off one particular timing value from the data sheet values (I can't remember which, suspect it might have been DYNAMICDAL).

Also at higher clock rates you need to change EMCDELAYCLK (I have 0x0000 for <= 96MHz, 0x1111 for 97 to 129MHz and 0x2222 above that).

Double check that you have CAS/RAS latencies configured identically between the memory controller and the SDRAM chip.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by suckfish on Thu Jun 20 23:12:26 MST 2013

Could be a timing problem resulting in each 16-bit word getting delayed by a clock cycle? Try backing off all the timing parameters and/or the clock rate and see if that fixes things?

I have the same part on a board running fine. I did find that when I pushed the clock rates I had to back off one particular timing value from the data sheet values (I can't remember which, suspect it might have been DYNAMICDAL).

Also at higher clock rates you need to change EMCDELAYCLK (I have 0x0000 for <= 96MHz, 0x1111 for 97 to 129MHz and 0x2222 above that).

Double check that you have CAS/RAS latencies configured identically between the memory controller and the SDRAM chip.

SDRAM data shifts

SDRAM data shifts

LPC43xx