lpcware

LPC4350 (LBGA256) SDRAM Clock problem

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Jun 15, 2016 by lpcware
Content originally posted in LPCWare by paulheays on Mon Dec 10 16:09:10 MST 2012
Our product uses the LPC4350 (LBGA256 package) with a Micron MT48LC4M32B2P configured to use DYCS1 area (0x30000000..0x3FFFFFFF).   We are also using the SD card interface and supplying the clock for this from the CLK0 pin.

Unfortunately we have had significant trouble getting the SDRAM to work in this configuration.  We have now discovered that the only way of getting the SDRAM in the DYCS1 area to work properly is by configuring the CLK0, CLK1 and CLK2 pins to function 0 (output SDRAM clocks EMC_CLK0, EMC_CLK1 and EMC_CLK3 respectively).

In an attempt to isolate this problem I used a Keil MCB4300 board running the Keil “Blinky” example code.  I modified the “Blinky” code to perform a test of the entire 16MB of SDRAM located in the DYCS0 area once the EMC port has been configured.  With CLK0 to CLK3 pins all set to function 0 (output SDRAM clocks EMC_CLK0, EMC_CLK1, EMC_CLK3 and EMC_CLK2 respectively) the RAM test passes. However if either CLK1 or CLK2 are set to any other function the RAM is either not accessible or the test fails.

Unfortunately this means that if we use the SDRAM we cannot use the SD card interface as the only other pin available for the SD card clock is PC_0 which is needed for other purposes.

Could this be why the Keil MCB4300 uses the SPI interface for the SD card and the Keil example code specifically configures CLK0 to CLK3 as EMC_CLKx  outputs?

I am quite desperate for a fix or work around to this problem as bugs in this chip have cost us significant time and money and have come very close to losing us a significant customer.  Having to redesign our complex board again is not an option for us.

Thanks in advance for you help.
Paul Heays.


Outcomes