topic Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM in LPC Microcontrollers

DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:04 GMT

Content originally posted in LPCWare by Dave on Tue Jul 19 10:04:19 MST 2011
The SDRAM has to be programmed before you can use it as a display buffer for the LCD. And before you can program the SDRAM, you have to setup the LPC1788 so it can talk to the SDRAM.

The SDRAM on this development board is a MT48LC2M32B2, which is a 2Mx32bit chip ( 8.38MB or 67.108Mb ).

Since all timing values for the LPC1788 are in units of CLK counts, and all timing values in the data sheet are in nanoseconds, the first thing I needed was a macro to convert these units.

Here is a macro for converting nanoseconds to CLK counts:
<code>
#include "LPC177x_8x.h"
#include "system_LPC177x_8x.h"

#define tCLK_ns ((double)EMCClock / 1000000000.0 )                   // CCLK period in ns
#define NS_2_CLKS(ns) ( (uint32_t)( (double)(ns) * tCLK_ns ) + 1 )   // convert ns to CCLKs
</code>

The EMCClock value is from the CMSIS, located in "system_LPC177x_8x.h", and is the current EMC clock value. The macro NS_2_CLKS converts a given value in nanoseconds to the equivalent number of clock cycles for the current EMC clock...

Another feature of the SDRAM is the order in which the BANK, ROW, and COLUMN are set. You can have BANK-ROW-COLUMN or ROW-BANK-COLUMN. I did some experimenting with this, and found a slight increase in performance when I used ROW-BANK-COLUMN order, but you can experiment with this yourself.

I defined a compiler switch to make it easier to change:
<code>
#define ROW_BANK_COLUMN    // default is BANK_ROW_COLUMN (ROW_BANK_COLUMN is ~0.2% faster...
</code>

So, here's how to setup the LPC1788 and the SDRAM...
<code>
/***********************************************************************************************
** Function name:    SDRAM_init
**
** Descriptions:     Initialize SDRAM (Synchronous Dynamic Random Access Memory)
**
** parameters:       None
** Returned value:   TRUE when complete
**
***********************************************************************************************/
uint32_t INIT_SDRAM( void )
   {
   uint32_t Temp = Temp;
   uint32_t CAS_Latency, RAS_Latency; // these can be 1, 2, or 3 clks
   uint32_t DelayConstant;
</code>

I used variables for the CAS and RAS latency values, as well as the delay constant so I could adjust them easily during development.

So the first thing to do is setup the LPC1788. This entails defining the SDRAM control signals, defining how we want the device to react to a reset signal, and enabling the power to the device (peripheral power), as follows:
<code>
   // configure SDRAM control signals
   // ------------------------------------------------------------------------------------------
   LPC_IOCON->P2_16 |= 1;              // CASN @ P2.16         (SDRAM Column Address Strobe)
   LPC_IOCON->P2_17 |= 1;              // RASN @ P2.17         (SDRAM Row Address Strobe)
   LPC_IOCON->P2_18 |= 1;              // CLK[0] @ P2.18       (SDRAM System Clock)
   LPC_IOCON->P2_20 |= 1;              // DYCSN[0] @ P2.20     (SDRAM Chip Select)
   LPC_IOCON->P2_24 |= 1;              // CKE[0] @ P2.24       (SDRAM Clock Enable)
   LPC_IOCON->P2_28 |= 1;              // DQM[0] @ P2.28       (SDRAM Data Input/Output Mask)
   LPC_IOCON->P2_29 |= 1;              // DQM[1] @ P2.29       (SDRAM Data Input/Output Mask)
   LPC_IOCON->P2_30 |= 1;              // DQM[2] @ P2.30       (SDRAM Data Input/Output Mask)
   LPC_IOCON->P2_31 |= 1;              // DQM[3] @ P2.31       (SDRAM Data Input/Output Mask)

   // configure for 32-bit external data bus
   // ------------------------------------------------------------------------------------------
   LPC_IOCON->P3_0 |= 1;               // D0 @ P3.0
   LPC_IOCON->P3_1 |= 1;               // D1 @ P3.1
   LPC_IOCON->P3_2 |= 1;               // D2 @ P3.2
   LPC_IOCON->P3_3 |= 1;               // D3 @ P3.3
   LPC_IOCON->P3_4 |= 1;               // D4 @ P3.4
   LPC_IOCON->P3_5 |= 1;               // D5 @ P3.5
   LPC_IOCON->P3_6 |= 1;               // D6 @ P3.6
   LPC_IOCON->P3_7 |= 1;               // D7 @ P3.7
   LPC_IOCON->P3_8 |= 1;               // D8 @ P3.8
   LPC_IOCON->P3_9 |= 1;               // D9 @ P3.9
   LPC_IOCON->P3_10 |= 1;              // D10 @ P3.10
   LPC_IOCON->P3_11 |= 1;              // D11 @ P3.11
   LPC_IOCON->P3_12 |= 1;              // D12 @ P3.12
   LPC_IOCON->P3_13 |= 1;              // D13 @ P3.13
   LPC_IOCON->P3_14 |= 1;              // D14 @ P3.14
   LPC_IOCON->P3_15 |= 1;              // D15 @ P3.15
   LPC_IOCON->P3_16 |= 1;              // D16 @ P3.16
   LPC_IOCON->P3_17 |= 1;              // D17 @ P3.17
   LPC_IOCON->P3_18 |= 1;              // D18 @ P3.18
   LPC_IOCON->P3_19 |= 1;              // D19 @ P3.19
   LPC_IOCON->P3_20 |= 1;              // D20 @ P3.20
   LPC_IOCON->P3_21 |= 1;              // D21 @ P3.21
   LPC_IOCON->P3_22 |= 1;              // D22 @ P3.22
   LPC_IOCON->P3_23 |= 1;              // D23 @ P3.23
   LPC_IOCON->P3_24 |= 1;              // D24 @ P3.24
   LPC_IOCON->P3_25 |= 1;              // D25 @ P3.25
   LPC_IOCON->P3_26 |= 1;              // D26 @ P3.26
   LPC_IOCON->P3_27 |= 1;              // D27 @ P3.27
   LPC_IOCON->P3_28 |= 1;              // D28 @ P3.28
   LPC_IOCON->P3_29 |= 1;              // D29 @ P3.29
   LPC_IOCON->P3_30 |= 1;              // D30 @ P3.30
   LPC_IOCON->P3_31 |= 1;              // D31 @ P3.31

   // configure for 32-bit external address bus
   // ------------------------------------------------------------------------------------------
   LPC_IOCON->P4_0 |= 1;               //A0 @ P4.0
   LPC_IOCON->P4_1 |= 1;               //A1 @ P4.1
   LPC_IOCON->P4_2 |= 1;               //A2 @ P4.2
   LPC_IOCON->P4_3 |= 1;               //A3 @ P4.3
   LPC_IOCON->P4_4 |= 1;               //A4 @ P4.4
   LPC_IOCON->P4_5 |= 1;               //A5 @ P4.5
   LPC_IOCON->P4_6 |= 1;               //A6 @ P4.6
   LPC_IOCON->P4_7 |= 1;               //A7 @ P4.7
   LPC_IOCON->P4_8 |= 1;               //A8 @ P4.8
   LPC_IOCON->P4_9 |= 1;               //A9 @ P4.9
   LPC_IOCON->P4_10 |= 1;              //A10 @ P4.10
   LPC_IOCON->P4_11 |= 1;              //A11 @ P4.11
   LPC_IOCON->P4_12 |= 1;              //A12 @ P4.12
   LPC_IOCON->P4_13 |= 1;              //A13 @ P4.13
   LPC_IOCON->P4_14 |= 1;              //A14 @ P4.14
   LPC_IOCON->P4_15 |= 1;              //A15 @ P4.15
   LPC_IOCON->P4_16 |= 1;              //A16 @ P4.16
   LPC_IOCON->P4_17 |= 1;              //A17 @ P4.17
   LPC_IOCON->P4_18 |= 1;              //A18 @ P4.18
   LPC_IOCON->P4_19 |= 1;              //A19 @ P4.19
   //LPC_IOCON->P4_20 |= 1;             //A20 @ P4.20
   //LPC_IOCON->P4_21 |= 1;             //A21 @ P4.21
   //LPC_IOCON->P4_22 |= 1;             //A22 @ P4.22
   //LPC_IOCON->P4_23 |= 1;             //A23 @ P4.23

   // Configure write enable for SDRAM...
   // ------------------------------------------------------------------------------------------
   LPC_IOCON->P4_25 |= 1;              // WEN @ P4.25

   // Enable EMC Reset, (both EMC resets are asserted when any type of reset occurs)
   // [Ref: LPC178x_7x_UM_1.4 page 32 ]
   // ------------------------------------------------------------------------------------------
   LPC_SC->SCS &= ~(1<<1);    // clears bit 1, which is the power on default state anyway...

   // Enable EMC power/clock control bit...
   // ------------------------------------------------------------------------------------------
   LPC_SC->PCONP   |= (1<<11);
</code>

Next thing to do is define the values for the variables at the beginning (CAS_Latency, RAS_Latency, and the DelayConstant).
I chose these values for functionality, but you can play around with them to see the effect they have on SDRAM performance.
The datasheet for the MT48LC2M32B2 has recommend values, based on the operating frequency.

I chose an arbitrary frequency of 100Mhz as a switch from lower latency to higher latency, as follows:
<code>
   if( SystemCoreClock < 100000000 )   // longer delay constant, and shorter CAS and RAS latency
      {                                //
      LPC_SC->EMCCLKSEL = 0x00000001; // EMC uses a clock rate at 1/2 CPU clock rate...
      LPC_SC->CLKOUTCFG = 0x00000110; // enables clock, sets clock source as CPU clk / 2...
      CAS_Latency = 1;
      RAS_Latency = 1;
      DelayConstant = 0x00000604;
      }
   else
      {
      LPC_SC->EMCCLKSEL = 0x00000000; // EMC uses a clock rate equal to CPU clock rate...
      LPC_SC->CLKOUTCFG = 0x00000100; // enables clock, sets clock source as CPU clk / 1...
      CAS_Latency = 2;
      RAS_Latency = 2;
      DelayConstant = 0x00000A05;
      }

   // [Ref: LPC178x_7x_UM_1.4 page 183 ]
   // ----------------------------------------------------------------------------------------------------------------------
   // Bit      Symbol         Description                                                                              Reset
   //                                                                                                                  Value
   // ----------------------------------------------------------------------------------------------------------------------
   // 4:0      CMDDLY         Programmable delay value for EMC outputs in command delayed mode. See                    0x10
   //                         Section 10.12.6. The delay amount is roughly (CMDDLY+1) * 250 picoseconds.
   // 7:5      -              Reserved. Read value is undefined, only zero should be written.                          NA
   // 12:8     FBCLKDLY       Programmable delay value for the feedback clock that controls input data sampling. See   0x02
   //                         Section 10.5.3. The delay amount is roughly (FBCLKDLY+1) * 250 picoseconds.
   // 15:13    -              Reserved. Read value is undefined, only zero should be written.                          NA
   // 20:16    CLKOUT0DLY     Programmable delay value for the CLKOUT0 output. This would typically be used in clock   0x00
   //                         delayed mode. See Section 10.12.6 The delay amount is roughly (CLKOUT0DLY+1) *
   //                         250 picoseconds.
   // 23:21    -              Reserved. Read value is undefined, only zero should be written.                          NA
   // 28:24    CLKOUT1DLY     Programmable delay value for the CLKOUT1 output. This would typically be used in clock   0x00
   //                         delayed mode. See Section 10.12.6 The delay amount is roughly (CLKOUT1DLY+1) *
   //                         250 picoseconds.
   // 31:29    -              Reserved. Read value is undefined, only zero should be written.                          NA
   LPC_SC->EMCDLYCTL   = DelayConstant;

   // Reset the EMC and put configuration back to power up reset (little-endian mode, 1:1 clock)
   // [Ref: LPC178x_7x_UM_0.01 page 156]
   // ------------------------------------------------------------------------------------------
   LPC_EMC->Control = 0x00000001;   // Disable Address mirror, leave EMC enabled...
   LPC_EMC->Config = 0x00000000;

   // define connection configuration [32 bit external bus address mapping]
   // ------------------------------------------------------------------------------------------
   #ifdef ROW_BANK_COLUMN
      LPC_EMC->DynamicConfig0 = 0x00004300; // row, bank, column, 32-bit
   #else
      LPC_EMC->DynamicConfig0 = 0x00005300; // bank, row, column, 32-bit
   #endif

   // define delays for RAS and CAS...
   // bits 1:0-RAS latency, bits 9:8-CAS latency (in CCLK cycle counts)
   // ------------------------------------------------------------------------------------------
   LPC_EMC->DynamicRasCas0 = RAS_Latency + (CAS_Latency<<8);    // reset value is 3 and 3

   // configure the dynamic memory read strategy. Note: This register is used for all four
   // dynamic memory chip selects. Therefore the worst case value for all of the chip selects
   // must be programmed.
   // [Ref: LPC178x_7x_UM_0.01 page 169 Table 117]
   // ------------------------------------------------------------------------------------------
   LPC_EMC->DynamicReadConfig = 0x00000001; // Command delayed strategy, using EMCCLKDELAY
                                             // (command delayed, clock out not delayed)
</code>

Also, in the above code, the Control, Config, DynamicConfig, DynamicRasCas, and DynamicReadConfig registers are programmed. The notes will give you an idea of what's going on, but I recommend you read the user's manual for a complete description of these registers.

The next thing to do is program the controller with the part specific timing values. This is where the macros at the beginning will come in handy.

These values are programmed as follows:
<code>
   // *** Taken from the MT48LC2M32B2 data sheet, page 47 ***
   // configure timing, from Table 18:
   // -6 (6ns part) timings (see marking on actual chip: MT48LC2M32B2-6)
   // NOTE: all timing values for LPC1788 are in units of CLK counts
   // ------------------------------------------------------------------------------------------
   LPC_EMC->DynamicRP   = NS_2_CLKS(18);     // tRP: precharge command period             (18ns)
   LPC_EMC->DynamicRAS = NS_2_CLKS(42);     // tRAS: active to precharge command period (42ns)
   LPC_EMC->DynamicSREX = NS_2_CLKS(70);     // tXSR: self-refresh exit time              (70ns)
   LPC_EMC->DynamicAPR = NS_2_CLKS(18);     // tAPR: last-data-out to active command time
                                             // note: no tAPR value, using tRCD value     (18ns)
   LPC_EMC->DynamicDAL = CAS_Latency+2;     // tDAL: data-in to active command time
                                             //       for CL=3, tDAL = 5 tCK
                                             //       for CL=2, tDAL = 4 tCK
                                             //       for CL=1, tDAL = 3 tCK
   LPC_EMC->DynamicWR   = (NS_2_CLKS(6)+1); // tWR: write recovery time is (12ns) UNLESS we're
                                             //      using AUTO PRECHARGE, then it's   (tCK+6ns)
   LPC_EMC->DynamicRC   = NS_2_CLKS(60);     // tRC: ACTIVE-to-ACTIVE command period      (60ns)
   LPC_EMC->DynamicRFC = NS_2_CLKS(60);     // tRFC: AUTO REFRESH period                 (60ns)
   LPC_EMC->DynamicXSR = NS_2_CLKS(70);     // tXSR: Exit self refresh to ACTIVE command (70ns)
   LPC_EMC->DynamicRRD = NS_2_CLKS(12);     // tRRD: active bank A to active bank B command
                                             //       latency                             (12ns)
   LPC_EMC->DynamicMRD = 2;                 // tMRD: LOAD MODE REGISTER command to ACTIVE or
                                             // REFRESH command time                      (2tCK)
</code>

With all of these parameters programmed, we are now ready to send commands to the SDRAM chip.

An important note:
<code>
   // *** Taken from the MT48LC2M32B2 data sheet, page 10 ***
   // ------------------------------------------------------------------------------------------
   // SDRAMs must be powered up and initialized in a predefined manner. Operational
   // procedures other than those specified may result in undefined operation. After power is
   // applied to VDD and VDDQ (simultaneously) and the clock is stable (stable clock is
   // defined as a signal cycling within timing constraints specified for the clock pin), the
   // SDRAM requires a 100us delay prior to issuing any command other than a COMMAND
   // INHIBIT or NOP. Starting at some point during this 100us period, and continuing at least
   // through the end of this period, COMMAND INHIBIT or NOP commands must be
   // applied.
   // When the 100us delay has been satisfied with at least one COMMAND INHIBIT or NOP
   // command having been applied, a PRECHARGE command should be applied. All banks
   // must then be precharged, thereby placing the device in the all banks idle state.
   // ------------------------------------------------------------------------------------------
</code>

so the first command we send to the SDRAM is a NOP command, and we wait for the 100us...
<code>
   // *** Taken from the MT48LC2M32B2 data sheet, page 17 ***
   // The NO OPERATION (NOP) command is used to perform an NOP to an SDRAM that is
   // selected (CS# is LOW). This prevents unwanted commands from being registered during
   // idle or wait states. Operations already in progress are not affected.
   // ------------------------------------------------------------------------------------------
   // Send command: NOP
   // (CLKOUT runs continuously; All clock enables are driven HIGH continuously)
   // ------------------------------------------------------------------------------------------
   LPC_EMC->DynamicControl = 0x00000183;

   // wait > 100us
   // ------------------------------------------------------------------------------------------
   for( Temp=NS_2_CLKS(100000); Temp; Temp-- );
</code>

The next command is the PRECHARGE-ALL command, and we set the correct refresh period, as follows:
<code>
   // *** Taken from the MT48LC2M32B2 data sheet, page 18 ***
   // The PRECHARGE command is used to deactivate the open row in a particular bank or
   // the open row in all banks. The bank(s) will be available for a subsequent row access a
   // specified time (tRP) after the PRECHARGE command is issued. Input A10 determines
   // whether one or all banks are to be precharged, and in the case where only one bank is to
   // be precharged, inputs BA0 and BA1 select the bank. Otherwise BA0 and BA1 are treated
   // as “Don’t Care.” After a bank has been precharged, it is in the idle state and must be
   // activated prior to any READ or WRITE commands being issued to that bank.
   // ------------------------------------------------------------------------------------------
   // Send command: PRECHARGE-ALL and set the shortest possible refresh period
   // ------------------------------------------------------------------------------------------
   LPC_EMC->DynamicControl = 0x00000103;
   LPC_EMC->DynamicRefresh = 0x00000001; // 1 x 16 = 16 CCLKs between SDRAM refresh cycles

   // wait >128 clks
   // ------------------------------------------------------------------------------------------
   for( Temp=128; Temp; Temp-- );

   // *** Taken from the MT48LC2M32B2 data sheet, page 18 ***
   // Regardless of device width, the
   // 64Mb SDRAM requires 4,096 AUTO REFRESH cycles every 64ms (commercial and industrial)
   // or 16ms (automotive). Providing a distributed AUTO REFRESH command every
   // 15.625us (commercial and industrial) or 3.906us (automotive) will meet the refresh
   // requirement and ensure that each row is refreshed. Alternatively, 4,096 AUTO REFRESH
   // commands can be issued in a burst at the minimum cycle rate (tRFC), once every 64ms
   // (commercial and industrial) or 16ms (automotive).
   // so... Refresh period (4,096 rows) tREF – 64ms
   // which gives a time of 15.625us per row, or 15625ns
   // ------------------------------------------------------------------------------------------
   // Set correct refresh period
   // ------------------------------------------------------------------------------------------
   LPC_EMC->DynamicRefresh = NS_2_CLKS(15625)>>4;     // Refresh units are x16

   // wait >128 clks
   // ------------------------------------------------------------------------------------------
   for( Temp=128; Temp; Temp-- );
</code>

And finally, we send the mode command, which tells the SDRAM what the burst length is, the type of burst, the latency, etc., as follows:

<code>
   // Set mode register in SDRAM
   // A0–A10 define the op-code written to the mode register
   // Bank select is A13-A14, address is A0-A12, data I/O mask is DQM0-DQM3...
   // ------------------------------------------------------------------------------------------
   // Mode register table for Micron's MT48LCxx (MT48LC2M32B2P ON FDI BOARD)
   //    bit 9:   Write Burst Mode: Programmed burst length(0), Single Location Access(1)
   //    bit 8~7: Operating Mode: Standard Operation(0) is the only thing defined
   //    bit 6~4: CAS latency: 001(1), 010(2), 011(3)
   //    bit 3:   Type of Burst: Sequential(0) or Interleaved(1)
   //    bit 2~0: Burst length: 000(1), 001(2), 010(4), 011(8), 111(Full Page)
   //

   #ifdef ROW_BANK_COLUMN // shift includes bank
      Temp = *((volatile uint32_t *)(SDRAM_BASE_ADDR|((0x02+(CAS_Latency<<4))<<12)));
   #else                   // shift excludes bank
      Temp = *((volatile uint32_t *)(SDRAM_BASE_ADDR|((0x02+(CAS_Latency<<4))<<10)));
   #endif

   // wait >128 clks
   // ------------------------------------------------------------------------------------------
   for( Temp=128; Temp; Temp-- );
</code>

Notice the shift distance changes depending on which configuration we're using? (ROW_BANK_COLUMN versus BANK_ROW_COLUMN)

The final step is to put the SDRAM into NORMAL operation by sending the NORMAL command, as follows:
<code>
   // ------------------------------------------------------------------------------------------
   //Send command: NORMAL
   // ------------------------------------------------------------------------------------------
   LPC_EMC->DynamicControl = 0x00000000;

   //Enable buffer
   LPC_EMC->DynamicConfig0 |= 0x00080000;

   return( TRUE );
   }
</code>

This will setup your SDRAM properly for the DK-57VTS-LPC1788 development kit.

Hope this helps,

-Dave

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:05 GMT

Content originally posted in LPCWare by Dave on Thu Jul 21 10:42:24 MST 2011
Another user (Marc Crandall) pointed out that the macro definition above is wrong, and he is correct! (Thanks Marc)

The macro is used to convert time in ns to clock ticks, as follows:

<code>
#define NS_2_CLKS(ns) ( (uint32_t)( (double)(ns) * tCLK_ns ) + 1 )   // convert ns to CCLKs
</code>

The reasoning for adding 1 was to force round up after the truncation by the type cast.

However, when using this macro to program registers like the EMCDynamictMRD register, the processor will add 1 clock cycle to the value stored.

Table 128 on page 174 of the LPC178x/7x User's manual (rev. 1.4) shows the following:
<code>
Table 127. Dynamic Memory Active Bank A to Active Bank B Time register (EMCDynamictRRD - address
           0x2009 C054) bit description
-----------------------------------------------------------------------------------------------------------------------
Bit       Symbol                     Value       Description                                                      Reset
                                                                                                                  Value
-----------------------------------------------------------------------------------------------------------------------
3:0       Active bank A to active    0x0 -       n + 1 clock cycles. The delay is in CCLK cycles.                 0xF
          bank B latency (tRRD)      0xE

                                     0xF         16 clock cycles (POR reset value).
31:4      -                                      Reserved. Read value is undefined, only zero should be written. NA
</code>

So, either each of the register definitions should have 1 subtracted from it, like this:
<code>
LPC_EMC->DynamicRP   = NS_2_CLKS(18)-1;     // tRP: precharge command period             (18ns)
</code>

or, the macro should be rewritten to remove the '+1', and the two other places it's used should have 1 added to them, like this:
<code>
#define NS_2_CLKS(ns) ( (uint32_t)( (double)(ns) * tCLK_ns ) /*+ 1*/ )   // convert ns to CCLKs
*
*
*
   // wait > 100us
   // ------------------------------------------------------------------------------------------
   for( Temp=NS_2_CLKS(100000+1); Temp; Temp-- );
*
*
*
   LPC_EMC->DynamicRefresh = NS_2_CLKS(15625+1)>>4;     // Refresh units are x16

</code>

Really, the delay probably isn't that important, since the loop overhead adds a lot more than a single clock cycle to the delay...

Anyway, this is something to be aware of...

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:06 GMT

Content originally posted in LPCWare by Arne on Wed Aug 10 01:26:05 MST 2011
Hi Dave,

got a question regarding your code:
<code>
#ifdef ROW_BANK_COLUMN // shift includes bank
    Temp = *((volatile uint32_t *)(SDRAM_BASE_ADDR|((0x02+(CAS_Latency<<4))<<12)));
#else                   // shift excludes bank
    Temp = *((volatile uint32_t *)(SDRAM_BASE_ADDR|((0x02+(CAS_Latency<<4))<<10)));
#endif</code>

What happens here? To me it seems as you generate an address and then get the value stored at that address. But Temp is then overwritten in the next for-loop.
BTW: what is the value of SDRAM_BASE_ADDR? Is it 0xA000 0000?

cheers, Arne

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:07 GMT

Content originally posted in LPCWare by Dave on Wed Aug 10 19:30:23 MST 2011
Hi Arne,

To answer your question, that's exactly what's happening. I know it seems weird, but when you're programming the SDRAM chip, it's "WHY" you're doing what you're doing, not "WHAT" is left after you do what you do ( not sure if that makes sense or not ).

If you read the data sheet for the this SDRAM chip, you'll find that programming it is a sequence of events. In this section of the code, I'm programming the MODE register. In the datasheet, on page 12, it states:
<code>
The mode register is used to define the specific mode of operation of the SDRAM. This definition includes the selection of a burst length, a burst type, a CL, an operating mode and a write burst mode, as shown in Figure 4 on page 13. The mode register is programmed via the LOAD MODE REGISTER command and will retain the stored information until it is programmed again or the device loses power. Mode register bits M0–M2 specify the burst length, M3 specifies the type of burst (sequential or interleaved), M4–M6 specify the CL, M7, and M8 specify the operating mode, M9 specifies the write burst mode, and M10 is reserved for future use. The mode register must be loaded when all banks are idle, and the controller must wait the specified time before initiating the subsequent operation. Violating either of these requirements will result in unspecified operation.
</code>

The truth table on page 16 shows the conditions necessary for using the LOAD MODE REGISTER command,
CS = L, RAS = L, CAS = L, WE = L, DQM = don't care, DQs = don't care, and most importantly the ADDR = the op-code

By note #6, you see that the A0–A10 define the op-code written to the mode register. Now, these are the actual pins on the chip, not the linear address lines. So, you have to figure out how to get the op code on these address lines.

That's why I adjust the address where I'm reading from, but I really don't care about WHAT I read (it's why I named the variable 'Temp' - I suppose I could have named it 'Junk'...)

Well, these lines are used by the EMC to set the bank, row, and column( or row, bank, and column depending on how you're setting it up ).
So you have to understand a little about how the EMC sets these lines, and how to translate what's on them to a linear addressing scheme.

ARM.COM comes in handy here.

for Row, Bank, Column : http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0269a/CCHEFEII.html
for Bank, Row, Column : http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0269a/Bgbgcgbf.html

if you look closely, you can see the shift for A10 (2Mx32 BRC) is to A20, or a shift of 10.
and the shift for A10 (2Mx32 RBC) is to A22, or a shift of 12.

So really, the value I'm reading from the address isn't important, it's the ADDRESS itself that's important, and that is why I did what I did...

Hope this helps,

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:07 GMT

Content originally posted in LPCWare by Arne on Thu Aug 11 09:09:43 MST 2011
Hi Dave,

had a look at Fig.4 of the Micron datasheet and you are right. But there's one thing that I miss:
<code>
LPC_EMC->DynamicControl = 0x00000083; /* send MODE command */
<code>
Or am I wrong?

BTW: on the Keil forum you posted some demo code for a Memorytest. You used a call to a function that sets three colors. I tried this with Teraterm, but can only set the display mode to VT... not ANSI. Did you achive color output with Teraterm? If so: how?

cheers, Arne

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:08 GMT

Content originally posted in LPCWare by Dave on Thu Aug 11 11:24:21 MST 2011
I'm not sure what you're asking here... sorry.

Wrong about what?

Assuming you're talking about setting the DynamicControl register, you can read about the bit definitions in Table 115 on page 166 of the User's Manual.

There it talks about which bits to set depending on what type of command you want to send to the SDRAM chip.

bits 8:7 set the mode command if they are 01
bit 6 is reserved, so it should be 0
bit 5 sets the clock control, and we want it enabled, so it should be 0
bits 4:3 are reserved, so they should be 00
bit 2 is the self refresh request mode, and we don't want to issue this request, so it should be 0
bit 1 is the clock out control, and we want it to keep running, so we set it to 1
bit 0 is the clock enable, and we want it enabled, so we set it to 1

in order from 8:0, we get 010000011, or 0x83...

Regarding TeraTerm, I have it set to emulate the VT525, and the routine to set the ANSI colors looks like this:
<code>
   #ifndef ESC
      #define ESC 0x1B
   #endif

   enum AttrType
      {
      ALLOFF      = 0,     // All attributes off
      BRIGHT      = 1,     // Bold on
      UNDERSCORE = 4,     // Underscore (on monochrome display adapter only)
      BLINKING    = 5,     // Blink on
      INVERSE     = 7,     // Reverse video on
      HIDDEN      = 8      // Concealed on
      };

   enum colorType
      {
      ANSI_BLACK       = 0,     // Black
      ANSI_RED         = 1,     // Red
      ANSI_GREEN       = 2,     // Green
      ANSI_YELLOW      = 3,     // Yellow
      ANSI_BLUE        = 4,     // Blue
      ANSI_MAGENTA     = 5,     // Magenta
      ANSI_CYAN        = 6,     // Cyan
      ANSI_WHITE       = 7      // White
      };

void ANSIsetcolor( enum AttrType Attr, enum colorType FrColor, enum colorType BkColor )
   {
   /* sequence: ESC[Ps;...;Psm */
   printf("%c[%d;%d;%dm", ESC, (int)(Attr), (int)(FrColor+30), (int)(BkColor+40));
   }

</code>

Hope this helps,

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:09 GMT

Content originally posted in LPCWare by Arne on Thu Aug 11 12:08:33 MST 2011
Hi Dave,

I'm missing the MODE command just in front of the address calculation. Shouldn't it be like this:
<code>
LPC_EMC->DynamicControl = 0x00000083; /* send MODE command */
#ifdef ROW_BANK_COLUMN // shift includes bank
    Temp = *((volatile uint32_t *)(SDRAM_BASE_ADDR|((0x02+(CAS_Latency<<4))<<12)));
#else                   // shift excludes bank
    Temp = *((volatile uint32_t *)(SDRAM_BASE_ADDR|((0x02+(CAS_Latency<<4))<<10)));
#endif
</code>
That's how I understand the "Mode Register" paragraph on pg.10.
Thanx for the ANSI color code - will give it a try tomorrow.

cheers, Arne

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:09 GMT

Content originally posted in LPCWare by Dave on Thu Aug 11 22:08:34 MST 2011
Now I understand your question...

It appears that the example code I posted is missing the following bit, just before the #ifdef ROW_BANK_COLUMN section. It should have looked like this:

<code>
   // ------------------------------------------------------------------------------------------
   // Send command: MODE
   // ------------------------------------------------------------------------------------------
   LPC_EMC->DynamicControl = 0x00000083;

   // Set mode register in SDRAM
   // A0–A10 define the op-code written to the mode register
   // Bank select is A13-A14, address is A0-A12, data I/O mask is DQM0-DQM3...
   // ------------------------------------------------------------------------------------------
   // Mode register table for Micron's MT48LCxx (MT48LC2M32B2P ON FDI BOARD)
   //    bit 9:   Write Burst Mode: Programmed burst length(0), Single Location Access(1)
   //    bit 8~7: Operating Mode: Standard Operation(0) is the only thing defined
   //    bit 6~4: CAS latency: 001(1), 010(2), 011(3)
   //    bit 3:   Type of Burst: Sequential(0) or Interleaved(1)
   //    bit 2~0: Burst length: 000(1), 001(2), 010(4), 011(8), 111(Full Page)
   //

   #ifdef ROW_BANK_COLUMN // shift includes bank
      Temp = *((volatile uint32_t *)(SDRAM_BASE_ADDR|((0x02+(CAS_Latency<<4))<<12)));
   #else                   // shift excludes bank
      Temp = *((volatile uint32_t *)(SDRAM_BASE_ADDR|((0x02+(CAS_Latency<<4))<<10)));
   #endif
</code>

I don't know what happened when I originally posted that code, and I can't seem to edit it now.

Maybe Kevin can re-enable my edit privileges and I can fix that post...

Anyway, you are correct - there is a piece of code missing, and it should be just as we discussed...

Hope this helps,

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:10 GMT

Content originally posted in LPCWare by wmues on Wed Aug 17 08:15:06 MST 2011
Dave,

a little comment on using NS_2_CLKS:

a) as EMCClock is a variable, the (double) cast will be executed in runtime. Not good...
I have used
<code>#define NS_2_CLKS(ns) ((((__EMC_CLK/10000) * ns)/100000)+1) </code>
but this is only possible inside system_LPC177x_8x.c.

b) Using NS_2_CLKS for delay loops is not OK, because NS_2_CLKS is calculating EMC Clocks and not CPU core clocks.

AND NOW I have a big question about the setup of the delay lines and the read strategy:

In table 16 of the datasheet, there is a definition of the read cycle parameters:
tsu(D) = 5.3..1.5 ns
th(D) = 3.7..5.2 ns

tsu(D) and th(D) are bounded to the positive edge of CLKOUT.

First, I have checked equation [1] on page 85:

tsu(D) + delay time of feedback clock - sdram access time - board delay time >= 0.

If you set tsu(D) to a NEGATIVE value (because it's ahead of CLKOUT),
and if you set "sdram access time" to a negative value (SDRAM setup time, ahead of CLKOUT), this
equation is making perfect sense for me. No problem.

But checking the hold time requirement

th(D) + sdram access time - board delay time - delay time of feedback clock >= 0.

does not make any sense to me!

From Fig. 19, I can see the requirement that the data from the SDRAM should be stable until
about 5.2ns after the rising edge of CLKOUT.

But typical SDRAMs have a hold time of 3ns! Then the data on the output is replaced by the new data.
So how on earth can somebody make a working SDRAM interface using delayed feedback? Getting 5.2ns
hold time will only be possible with delay feedback = 0 and a delayed CLKOUT.

As anybody is using delayed feedback without delayed CLOCKOUT, there must be some errors in the doumentation, I assume?

And furthermore: 5.3ns setup time and 5.2ns hold time adds up to a data valid time of 10.5ns.
Given the uncertancies in the delay lines, it would be impossible to create a working SDRAM interface at 80 MHz EMC Clock.
Maybe 50..60 MHz, no more.

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:10 GMT

Content originally posted in LPCWare by Marc Crandall on Wed Aug 17 12:55:27 MST 2011
I would say that using NS_2_CLKS for the delay is OK because the delays are minimums only. So the EMC clock will either be the CPU clock or the CPU clock/2 so you will in some cases be waiting twice as long as necessary.

Also the for loop for a delay is really only an approximation as even that simple for loop compiles to multiple instructions and clock cycles per loop.

I wrote a similar driver in assembly but for an LPC2478 board. My personal opinion is the inefficiencies in the C driver setup are worth the advantage of using C over assembly.

BUT! a bigger issue with the NS_2_CLKS is the incorrect calculation of both EMCClock and __EMC_CLK in system_LPC177x_8x.c (See my other post: http://www.lpcware.com/content/forum/emc-clock)

Also, I'm using uVision as my development environment and I "ported" Dave's driver to uVision INI file so that I can use the SDRAM as part of the C stack and heap.

If anyone is interested in this I can post it here.

BTW - How are you guys using your SDRAM? is it only for explicit buffers for graphics or something? I plan on letting the linker use the SDRAM as it likes so I am going to configure the SDRAM and external Flash in a bootloader.

Cheers.

Marc

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:11 GMT

Content originally posted in LPCWare by Dave on Wed Aug 17 22:05:01 MST 2011
Hi Wmues,

Thank you for your constructive criticism.

Why do you believe it is "not good" to typecast in "runtime"? I'd like to understand your thinking on this.

Also, I think I understand your thoughts on the delays, and although Marc's point is correct, for readability sake, I should have made a different macro for delays; one that used the MCU clocks, and not the EMC clocks. Thanks for pointing this out.

Now, regarding your confusion about the data sheet values, my interpretation of the values listed in the table are absolute value. Their relative timing sign (+/-) is added based on what relative location you are referring to.

In the case of the read values, relative to the rising edge of the clock, the tsu(D) value would be negative and the th(D) would be positive, simply because you set T(0) to the rising edge of the clock signal.

If you changed your relative perspective, the signs could both be positive or negative... I hope this makes sense.

Regarding setting up these values, I'll have to do some more reading before attempting to verbalize specifics of why the delay constants I have work... I actually found them empirically (trial and error)...

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:12 GMT

Content originally posted in LPCWare by wmues on Thu Aug 18 02:46:24 MST 2011
Dave,

if you write "(double) variable", then the compiler will insert a call to a floating point runtime library (because the content of variable is not known at compile time), and all the calculations in NS_2_CLOCKS will be made with the floating point runtime library.

Is this your intention?

Marc,

you wrote:
" So the EMC clock will either be the CPU clock or the CPU clock/2 so you will in some cases be waiting twice as long as necessary."
This is not correct. If the EMC clock is half the CPU clock, the computed count is only half as big, and the loop duration (running at CPU clock speed) is only half as expected.

I am using the SDRAM as LCD buffer, code storage and data storage.

regards

Wolfgang

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:12 GMT

Content originally posted in LPCWare by Marc Crandall on Thu Aug 18 07:20:54 MST 2011
Hi Wolfgang,

Yes, you are right. I got my logic backwards there. I guess there are 2 reasons why Dave and I have not had any problems using this method:

1) a for loop like this will probably compile to something like:
<pre>
                LDR     R4,=loop_count_100        ; loop_count_100 * YYY ns ~ 100ms
Wait_0          SUBS    R4, R4, #1                ; loop, each clock cycles is ~XXXns @ XXX MHz CPU clock
                BNE     Wait_0                    ; 1 loop = BNE (3 cyc) + SUBS (1 cyc) = 4 cyc ==> YYY ns
</pre>
and hence will be 4 clk per loop and will hence be a long enough delay even at CPU/2 calculation.

2) As I mentioned above the calculation of EMCClock in the system...c file is incorrect and could actually be calculated as CPU clock even in cases where it is CPU/2.

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:13 GMT

Content originally posted in LPCWare by Dave on Thu Aug 18 11:04:07 MST 2011
Hi Wolfgang,

I guess I wasn't worried about the size of the code, since I use floating point calculations all over the place (in other parts of my system)...

but I see your point for conservation of code size. Since timing isn't a big issue for me during initialization, any time overhead can be ignored here...

After some investigation, I have an additional point to share:

You stated:
<code>
I have used
#define NS_2_CLKS(ns) ((((__EMC_CLK/10000) * ns)/100000)+1)
but this is only possible inside system_LPC177x_8x.c.
</code>

Even after using Marc's fix, which redefines __EMC_CLK to be based on the __CORE_CLK, and not the __PLL0_CLK(OSC_CLK) value, these values are static at the time of compilation.

In other words, what happens to __EMC_CLK if you execute the following line of code during initialization?
<code>
LPC_SC->EMCCLKSEL = 0x00000001; // EMC uses a clock rate at 1/2 CPU clock rate...
</code>

if you have the divider value initially set to 0 (which means a divider of 1) and dynamically change this value during initialization, after you run SystemCoreClockUpdate(), your NS_2_CLKS(ns) macro would generate the wrong value... (I think...)

Does that make sense?

I believe using the variable in the macro (which is re-calculated after a call to SystemCoreClockUpdate()) keeps everything true.

Any thoughts?

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:13 GMT

Content originally posted in LPCWare by wmues on Fri Aug 19 01:54:07 MST 2011
Hi Marc,

how do you code a for() delay loop which will not optimized away by the compiler?

My solution was to make the count variable volatile, but this will give a very ugly code....

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:14 GMT

Content originally posted in LPCWare by wmues on Fri Aug 19 01:59:34 MST 2011
Hi all,

I want to share my version of NS_2_CLKS here:

<code>
/* Transform ns into clock cycles (runtime, only 32bit multiplications):
* Valid input range: Clock < 995 MHz, ns = 0..1000000 (1ms)
*
* a) Divide Clock by 16. This gives enough headroom for step b).
* b) Multiply Clock by 69. This will adjust for decimal/binary divisor.
* This computation will overflow for a clock > 995 MHz!
* This computation will give results 0,5% larger than the real value.
* c) Divide Clock by 1048576 (2^20). This will give enough headroom for step d).
* d) Multiply Clock by ns. This will not overflow for ns = 0..1000000 (1ms).
* e) Divide Clock by 4096 (2^12). This will give value in clocks.
* f) Add 1 to account for rounding.
* (Use runtime computations because frequencies may change in runtime).
*/
#define NS_2_EMC_CLKS(ns) ((((((EMCClock >> 4)*69) >> 20)*(ns))>>12)+1)
#define NS_2_CPU_CLKS(ns) ((((((SystemCoreClock >> 4)*69) >> 20)*(ns))>>12)+1)
</code>

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:15 GMT

Content originally posted in LPCWare by wmues on Fri Aug 19 06:43:56 MST 2011
Hi all,

I have done a short delay loop which is compatible with compiler optimisation:

<code>
// Delay loop for short busy waits
static inline void wait_clocks( unsigned int clocks)
{
   do {
      asm("":::"memory"); // hint for gcc: do not remove this loop!
   } while (--clocks);
}
</code>

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:15 GMT

Content originally posted in LPCWare by Marc Crandall on Fri Aug 19 08:24:02 MST 2011
Good question.
What compiler are you using? I'm using Keil's armcc. The for loop delay as written by Dave above is not being optimized away with my current settings, however you are right it may very well be if/when I change my optimization settings. (although I'm not sure of this?)

You can always flag the section with --no_remove (or similar depending on you compiler/linker)

why does making the variable volatile make "ugly code"? What I think I will do in the end in insert some inline assembly for these delay loops.

If you make the variable volatile and see what assembly is generated you can quickly find out the number of clock cycles per loop and divide the loop count accordingly.

For example:

<pre>
     for(i = 0xFF; i ; i--);
000004 4608              MOV      r0,r1
000006 e002              B        |L1.14|
                  |L1.8|
000008 f1a00101          SUB      r1,r0,#1
00000c 4608              MOV      r0,r1
                  |L1.14|
00000e 2800              CMP      r0,#0
000010 d1fa              BNE      |L1.8|
;;;12
;;;13
;;;14         for(j = 0xFF; j ; j--);
000012 f04f01ff          MOV      r1,#0xff
000016 4a07              LDR      r2,|L1.52|
000018 6011              STR      r1,[r2,#0] ; j
00001a e005              B        |L1.40|
                  |L1.28|
00001c 4905              LDR      r1,|L1.52|
00001e 6809              LDR      r1,[r1,#0] ; j
000020 f1a10101          SUB      r1,r1,#1
000024 4a03              LDR      r2,|L1.52|
000026 6011              STR      r1,[r2,#0] ; j
                  |L1.40|
000028 4902              LDR      r1,|L1.52|
00002a 6809              LDR      r1,[r1,#0] ; j
00002c 2900              CMP      r1,#0
00002e d1f5              BNE      |L1.28|
</pre>

So in this case "j" is volatile and "i" is not. Just count up the clock cycles in each loop and divide the initial count - should work.

But really this is a very minor delay that is only done in init so you could just live with the extended delays. (i.e. just make it volatile and know you are waiting several times the required minimums)

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:16 GMT

Content originally posted in LPCWare by Dave on Tue Aug 23 21:21:09 MST 2011
Okay, that's pretty cool - two multiplies and some shifting...

I looked around on the net for some more tricks on "time efficient" coding, and ran across this:

http://www.hackersdelight.org/divcMore.pdf

just wanted to share.

Thanks again Wolfgang,

Re: DK-57VTS-LPC1788 - Configuring the EMC for SDRAM

lpcware — Wed, 15 Jun 2016 17:27:16 GMT

Content originally posted in LPCWare by PhilYoung on Wed Mar 21 10:57:01 MST 2012
This code seems to have a potential problem in that it cannot be guaranteed to perform correctly if it's compiled with optimization enabled.

The problem is that the volatile only qualifies the r-value, not the l-value and the value assigned to temp is not required later, therefore the optimization can completely remove the access to memory that sets up the mode command on the address pins.

In order to ensure that it is not completely removed either optimization needs to be disabled for this section, or the value needs to be assigned to something that prevents the compiler from optimizing it away.

probably the safest solution, which I often use for this type of issue, is simply to declare a global volatile unsigned variable and then whenever I need to ensure a read occurs I simply assign the result to this variable. As the variable is a global volatile there is no way the compiler can optimize the assignment away which then means the code is safe at all optimization levels.