LPC1788 and SDRAM

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC1788 and SDRAM

939 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by marcolando on Fri Feb 12 11:58:15 MST 2016
Hy guys,
I think I've a problem with an SDRAM (Micron MT48LC4M32) connected to the processor.
After the initialization I run a very very simple test:
long EMC_Test(void)
{// test SDRAM

long * SDRAM_ptr = RAM_BASE;
long i, count;

count = 0;
for (i = 0; i < RAM_CELL; i++)
{// write data
*SDRAM_ptr = i;// write data to SDRAM
if(*SDRAM_ptr++ == i)
count++;
}
return (count >> 6);// return value in kByte
}

and doing so it works...
but if I do the same test splitting write to memory and read from memory in two separate loops the test fails...
long EMC_Test(void)
{// test SDRAM

long * SDRAM_ptr = RAM_BASE;
long i, count;

count = 0;
for (i = 0; i < RAM_CELL; i++)
{// write data
*SDRAM_ptr++ = i;// write data to SDRAM
}

SDRAM_ptr = RAM_BASE;

for (i = 0; i < RAM_CELL; i++)
{// read data
if(i == *SDRAM_ptr++)// read data from SDRAM
count++;
}

return (count >> 6);// return value in kByte
}

Any ideas to start my investigation?
Thank you very much in advance,
Marco.
Labels (1)
0 Kudos
4 Replies

653 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by starblue on Fri Feb 19 03:33:43 MST 2016

Quote: marcolando

[read directly after write]
and doing so it works...
but if I do the same test splitting write to memory and read from memory in two separate loops the test fails...
Any ideas to start my investigation?


This is because the EMC does caching (called buffers in the documentation). So the SDRAM doesn't need to work at all for a small RAM test to succeed (up to 16 words if I remember correctly).
0 Kudos

653 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by marcolando on Fri Feb 19 01:03:14 MST 2016
I can say I've solved the problem!
Actually, I have got several problems...
First, there was a mistake in the initialization of the register DYNAMICCONFIG0; after I've been fixed it, things were better but I still had some cell with corrupted data (two words out four were corrupted).
Reading a lot of conversations and doing some search on the web, I focused my attention to connection of the line BA0 and BA1 that should be connected "always" to the pin A13 and A14 of the uC. That was not so on my board...
I fixed the connections, but at this point I needed to tune the command delay strategy.
Now the simple memory test works and I can go ahead with an intensive test.
Thank you very much to the community.

Marco.
0 Kudos

653 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by hparracho on Mon Feb 15 11:58:56 MST 2016
Check this article, it may help (it sure did help me track some initialization and solder problems in protos):

http://www.esacademy.com/en/library/technical-articles-and-documents/miscellaneous/software-based-me...

Source code:
http://www.embedded.com/design/embedded/source-code/4200237/memtest-zip
0 Kudos

653 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by wheels on Fri Feb 12 14:30:46 MST 2016
I'd question whether your initialization is correct. I'm not that familiar with SDRAM yet, but to me the problem looks as though the value you're writing may be persisting on the data bus through capacitance, and your single loop code allows the data to be read back before it decays away.

Try using the single loop, but putting a significant delay between the write and the read. If you get the same failure, then you aren't writing to SDRAM successfully.

Another test would be to use a single loop, but write two locations with different values each iteration, then read them back in order.

It may be worth doing a search on "memory test algorithm" or "RAM test" to be aware of some of the tricky bits involved in testing memory.
0 Kudos