AM57xx/DRA7xx DDR3-RAM Initialization

Hi,

I will ask the factory team to comment.

One can find the steps for initialize the DDR3 controller in chapter "EMIF Programming Guide" of the Technical Reference Manual (which is under NDA).

I want to write/read some patterns to/from the DDR3 controller over CS_DAP and interpret the results. Usually I do this without the intervention of the cpu core -> like I only do read-/writeMemory over JTAG-Emulation.

I do not use the CCS for this.

Peter Haake said:

I want to write/read some patterns to/from the DDR3 controller over CS_DAP and interpret the results. Usually I do this without the intervention of the cpu core -> like I only do read-/writeMemory over JTAG-Emulation.

I do not use the CCS for this.

Are you using Lauterbach or some other JTAG device?  You definitely should be using some kind of JTAG debug to look into this.  If you're using the wait-in-reset mode you should be able to connect to the CPU, set a hardware breakpoint at the MLO entry point, and then single step through your software that is configuring DDR3 (e.g. u-boot SPL).  After the configuration is complete I generally open up a memory window to the DDR space and try writing things like "0xdeadbeef", etc. and checking what comes back in the memory window to better understand how it's failing.  There are many failure modes.  A few of them are captured here:

http://processors.wiki.ti.com/index.php/Common_DDR_Issues

If you can provide some details in terms of how your DDR is failing that will make it easier for us to help you determine the issue.

Brad

A little background information: our company sells production and test equipment for electronic devices. So we use our own JTAG emulation hardware to get access to the processor. My task is to check the connection of the DDR3-RAM ICs.

So what I want to know is:

1. How can I get the DDR3-RAM to work ?

2. Which sequence is needed ?

3. Do I need the CPU (Cortex-A15, -M4 etc.) for this or can I do this with Read-/WriteMemory over JTAG emulation ?

4. Which PLLs have to be configured properly to get the DDR3 controller to work (see 2.).

5. Why is there such a big difference in the Technical Reference Manuals (TRM) of the AM57xx and DRA7xx telating to the init sequence of the EMIF ? I thought both processors architecture were similar.

6. AFAIK the DDR3 controller does the init sequence for the RAM IC itself, is this right ? Does that mean it modifies the Mode Registers of the DDR3 IC automatically ?

Peter Haake said:

1. How can I get the DDR3-RAM to work ?

2. Which sequence is needed ?

This is described in great detail in the TRM in Section 15.3.5.1.1.1 "EMIF Configuration Sequence".

Peter Haake said:

3. Do I need the CPU (Cortex-A15, -M4 etc.) for this or can I do this with Read-/WriteMemory over JTAG emulation ?

It's not required to configure the DDR3 using the A15.

Peter Haake said:

4. Which PLLs have to be configured properly to get the DDR3 controller to work (see 2.).

DPLL DDR is what controls the frequency observed on the bus.  However, you're going to want to configure DPLL CORE too, since that's what clocks the L3 interconnect that "feeds" the memory controller.

Peter Haake said:

5. Why is there such a big difference in the Technical Reference Manuals (TRM) of the AM57xx and DRA7xx telating to the init sequence of the EMIF ? I thought both processors architecture were similar.

I just compared TRM Section 15.3.5.1.1.1 "EMIF Configuration Sequence" between the two and they are identical.  I compared SPRUHZ6E (AM572x TRM Rev E) with the DRA75x TRM Rev AB (this document is only available under NDA).

Peter Haake said:

6. AFAIK the DDR3 controller does the init sequence for the RAM IC itself, is this right ? Does that mean it modifies the Mode Registers of the DDR3 IC automatically ?

Correct.  Very specific details on the programming of the mode registers are given in Section 15.3.4.7.2 "DDR3 SDRAM Initialization".

Let me 1st thank you for the answers.

to 4. Is there any requirement for the clock frequency rate of the DPLL_DDR and DPLL_CORE (for the L3 interconnect) ?

to 5. I used the previous Rev. of the AM57xx TRM Rev. D and TI changed the whole chapter. Now it looks the same.

Thanks,

Peter

Peter Haake said:

to 4. Is there any requirement for the clock frequency rate of the DPLL_DDR and DPLL_CORE (for the L3 interconnect) ?

Yes, there are many requirements!

• AM572x Data Manual Table 5-9. Maximum Supported Frequency
  • EMIF_DLL_FCLK
  • EMIF_PHY1_FCLK
  • EMIF_PHY2_FCLK
  • EMIF1_ICLK
  • EMIF2_ICLK
  • L3_CLK
  • L3_CLK1
  • L3_CLK2
• AM572x Data Manual Table 6-13. DPLL Type A Characteristics
• Also keep in mind that DDR3 (i.e. the DRAM itself, not the processor) imposes a MINIMUM frequency of 303 MHz.

Peter Haake said:

to 5. I used the previous Rev. of the AM57xx TRM Rev. D and TI changed the whole chapter. Now it looks the same.

I'm glad we're aligned now.  Thanks for confirming.

Hello again,

I've tried to start a project in CCS 6.1.1 with a DRA7xx prerelease device (OMAP XS5777) but I can only choose a AM57xx which is very similar. I'm using a XDS100v2 debugger but I can't connect to the DRA7xx.

Do you know which *.gel files are necessary to start a debug session with a DRA7xx. The output of the console is the following:

CortexA15_0: GEL Output: --->>> omap5430_memory_map_init DONE !!! <<<---
IcePick_D: GEL Output: Ipu RTOS is released from Wait-In-Reset.
IcePick_D: GEL Output: Ipu SIMCOP is released from Wait-In-Reset.
IcePick_D: GEL Output: IVAHD C64 is released from Wait-In-Reset.
IcePick_D: GEL Output: IVAHD ICONT1 is released from Wait-In-Reset.
IcePick_D: GEL Output: IVAHD ICONT2 is released from Wait-In-Reset.
CS_DAP_DebugSS: GEL Output: --->>> force_efuse <<<---
CS_DAP_DebugSS: GEL Output: ---<<< force_efuse >>>---
CS_DAP_DebugSS: GEL Output: --->>> GP device, no FW settings needed. <<<---
CS_DAP_DebugSS: GEL Output: ---<<< Firewalls settings >>>---
CS_DAP_PC: GEL Output: --->>> GP device <<<---
CS_DAP_PC: GEL Output: Cortex-A15 1 is not in WIR mode so nothing to do.
CortexA15_0: GEL Output: --->>> Start WDT2 Watchdog Timer is disabled <<<---
CortexA15_0: GEL Output: --->>> End WDT2 Watchdog Timer is disabled <<<---
CortexA15_0: GEL Output: >> START Fill_Emif_registers
CortexA15_0: GEL Output: >> START ==> EMIF1 and EMIF1 DDR IOs config (CTRL_MODULE_CORE_PAD module)
CortexA15_0: GEL Output: >> START dmm_settings_board
CortexA15_0: GEL Output: >> END dmm_settings_board
CortexA15_0: GEL Output: --->>> omap5430_startup_sequence DONE !!!!!  <<<---
CortexA15_0: File Loader: Verification failed: Values at address 0x0000000000000020 do not match Please verify target memory and memory map.
CortexA15_0: GEL: File: D:\WorkSpace\Embedded_C\CCS\DRA7xx_CA-15_XDS100v2\Debug\DRA7xx_CA-15_XDS100v2.out: a data verification error occurred, file load failed.
CortexA15_0: Unable to terminate memory download: NULL buffer pointer at 0x3aa4

As you can see I'm already using some*.gel files for initialization.

Thanks for tips.

wbr,

Peter

Sorry for the delay.  I've been traveling.

Peter Haake said:

Do you know which *.gel files are necessary to start a debug session with a DRA7xx. The output of the console is the following:

Gel files are optional.  You should be able to power up one of these boards and connect to the A15 with no gel files. 

Peter Haake said:

CortexA15_0: File Loader: Verification failed: Values at address 0x0000000000000020 do not match Please verify target memory and memory map.
CortexA15_0: GEL: File: D:\WorkSpace\Embedded_C\CCS\DRA7xx_CA-15_XDS100v2\Debug\DRA7xx_CA-15_XDS100v2.out: a data verification error occurred, file load failed.
CortexA15_0: Unable to terminate memory download: NULL buffer pointer at 0x3aa4

What are you trying to load, and why are you trying to load address 0x20?  That would be in the GPMC space.  It sounds like perhaps you built a program without a proper linker command file and everything was linked to address 0 as a result.

Hello again,

so, finally I managed to get the DDR3-RAM controller to work with our toolchain with the help of the .gel files (reverse engineering of the config described in the .gel files). But I have a fundamental problem with the used HW leveling of the controller. My goal is to detect defective signals (data bus pins for example) of the DDR3-RAM for use in the production of our customers (so they know which of the signals is open, short etc.).
As an example I cut the line D27 of the EMIF2 on my board to provoke such an error. The consequence is that all data bus signal of the upper byte of the 32-bit wide EMIF2 fail with random errors (random means that they are not stable HIGH/LOW). I assume this has something to do with HW leveling.
So I want to know if it is possible to use SW leveling (at all) to get a pin diagnostic test of the EMIF1/2 ?



Thanks and Happy Holidays,
wbr Peter

Peter,

I have seen some emails referring to this E2E thread.  This discussion needs to remain in E2E.  Please summarize the problem that you are trying to solve.  It appears that you are trying to implement a tooling solution for validating DDR3 operation in a board production environment while using a JTAG emulator.  Is this correct?

Tom

Hello Tom,

I just want to answer for my collegue Peter, which is not in the office today.

Yes this is correct. We providing tools for board level testing in the production environment. In between to boundary scan we also provide solutions using the debug interface of a processor and the processor itself as a extended measurement device in the test. In this case we talk about the at speed RAM-Interconnection-Test Part, where we actually can detect defective Data and Addresslines if the RAM-Controller is configured properly.

With the Jacinto6 Devices (DRA74x/AM57x) it unfortunately may not appear when there are defective lines in production process. It seems that the hardware leveleing routines can not work properly then, which makes sense for us.

The Idea now is to capture the needed registers from a well configured "Golden Board" and use these values to set up the RAM-Controller properly for every manufactured board, which we can assume as identical seen from the layout. Assuming we then can Write-/Read our Testpatterns to the DDR to detect exeactly which RAM-Lines are defective.

The first question for us would be. Can you confirm that this approach should be possible? If yes the next question for us is how to set up the controller properly without using the hardware leveling.

Many Thanks for your help.

RIcardo

Ricardo,

For Catalog (AM57xx), we only support HW leveling. For Auto (DRA7xx), they support both HW leveling and SW leveling at this time. Moving forward, Auto is also planning to move to HW leveling only.

 

Given this issue, here is what I would recommend.

• Perform HW leveling (recommended procedure)

• Derive the HW leveling values by reading the following STATUS registers for different timings

  • RD_DQS_SLAVE_RATIO : EMIF_PHY_STATUS_7/8/9/10/11

  • FIFO_WE_SLAVE_RATIO : EMIF_PHY_STATUS_12/13/14/15/16

  • WR_DQS_SLAVE_RATIO : EMIF_PHY_STATUS_22/23/24/25/26

  • WR_DATA_SLAVE_RATIO : EMIF_PHY_STATUS_17/18/19/20/21

• Note that the above values will vary across boards, memory types, processor and may slightly vary on a given board across iterations

• Pick an average HW leveling timing set across a big sample size. Program these “derived” average HW leveling values into following registers and disable HW leveling

  • RD_DQS_SLAVE_RATIO : EMIF_EXT_PHY_CONTROL_7/8/9/10/11

  • FIFO_WE_SLAVE_RATIO : EMIF_EXT_PHY_CONTROL _2/3/4/5/6

  • WR_DQS_SLAVE_RATIO : EMIF_EXT_PHY_CONTROL_17/18/19/20/21

  • WR_DATA_SLAVE_RATIO : EMIF_EXT_PHY_CONTROL_12/13/14/15/16

 

The procedure of disabling HW leveling is NOT a TI recommended approach and we cannot extend any further support on this approach.

 

We have these additional questions:

• HW leveling is an Industry standard/JEDEC method which cannot work on a defective board. How are the tools addressing this? This particular solution seems to be working backwards vs. where the DDR speeds/trends are going that mandate tuning of timings based on HW leveling

• Why can’t your implementation use the BSDL tools?

• How is this done with other processors? How is this scalable to higher speeds/newer DDR standards?

Tom

Peter, Ricardo,

It appears to me that the best solution to meet your needs now and in the future is to load a binary into internal memory for one of the processor cores and then to have that program configure and validate the DDR interface operation.  I do not see how leveling success or failure will provide enough granularity to determine exact failure modes.

Tom

Hello Tom,

I will first reply to your two previous posts.

1. So your advice is to make a successful HW leveling with a set of golden boards (the signal traces should have the same shape, size etc a.k.a. the same revision) -> then build a average of each EMIF_PHY_STATUS_x register -> then write those in the appropriate EMIF_EXT_PHY_CONTROL_x register for the actual production test.

My question is how is the SW leveling initialization sequence of the EMIF controller different to the HW leveling variant ? I found a chapter ("15.3.4.8.2 Software Leveling") which describes the SW leveling sequence isolated to the rest of the EMIF controller initiailization.

Tom Johnson16214 said:

HW leveling is an Industry standard/JEDEC method which cannot work on a defective board. How are the tools addressing this? This particular solution seems to be working backwards vs. where the DDR speeds/trends are going that mandate tuning of timings based on HW leveling

2. AFAIK one can only test the DDR3_D[x...y] pins because the address and control lines are necessary for a successful RAM init (write of the Mode Register 0 - 2). So in best case only possible errors on data lines/signals could be recognized.

Tom Johnson16214 said:

Why can’t your implementation use the BSDL tools?

3. We also use Boundary Scan but there are some DDR3 Memory ICs which are not capable of the low frequencies used because of the length of the scan chain of the processor. Also open pins are not identifiable because there is no counterpart. Besides because of the long scan chain (which results in low frequencies) one cannot meet the requirement of the refresh cycle rate. 

Tom Johnson16214 said:

How is this done with other processors? How is this scalable to higher speeds/newer DDR standards?

4. This depends on the documentation and realization of the DDR3 controller in the respective processor.

Now I have a more practical question:

Like I already said in a previous post it is possible for me now to access the DDR3-RAM with 2 customer boards (both are DRA7xx -> one has the label of a OMAP XS5777; one uses Hynix H5TQ4G63CFR, the other ISSI IS46TR16256AL).

Now I got another board from another customer which uses Micron MT41K128M16JT-125ITK . Additionally it has a ECC memory module, so there are 2x16-bit devices for Data and 1x8-Bit for ECC on this board (8-Bits are not used on the ECC module).The memory module has also the ability of automatic self refresh (ASR) which the other memory modules of the working boards have not (AFAIK). In addition, the memory device runs with 1.35 V so it is a low power DDR3-RAM.

That in my opinion are the main differences (the timings seem equal to me): ECC, ASR, VDD (1.35 to 1.5 V).

Problem is that the initialization sequence which works with the 2 other boards doesn't work with this one. Do you have any advice for this one ?

wbr, Peter

Hello again,

to 5.

I write in this topic/thread because I think this is a general problem.
So I recently got a new board from the customer which I tested with CCS 6.1.2. I used the .gel file "gpevm_am572x.gel" to access the device which is a AM5728 SR 2.0.

The following log appears:

CortexA15_0: GEL Output: --->>> AM572x Cortex A15 Startup Sequence In Progress... <<<---
CortexA15_0: GEL Output: --->>> AM572x Cortex A15 Startup Sequence DONE! <<<---
CortexA15_0: GEL Output: --->>> AM572x GP EVM <<<---
CortexA15_0: GEL Output: --->>> AM572x Target Connect Sequence Begins ... <<<---
CortexA15_0: GEL Output: --->>> I2C Init <<<---
CortexA15_0: GEL Output: --->>> AM572x Begin MMC2 Pad Configuration <<<---
CortexA15_0: GEL Output: --->>> AM572x End MMC2 Pad Configuration <<<---
CortexA15_0: GEL Output: --->>> WARNING: UNKNOWN DEVICE ID (0x00000000), PLEASE UPDATE GEL FILES !!!! <<<---
CortexA15_0: GEL Output: --->>> ERROR!!! UNKNOWN device type! <<<---
CortexA15_0: GEL Output: --->>> Reset occurs <<<---
CortexA15_0: GEL Output: --->>> PRCM Clock Configuration for OPPNOM in progress... <<<---
CortexA15_0: GEL Output: --->>> AM572x PG2.0 GP device <<<---
CortexA15_0: GEL Output:     Cortex A15 DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:     Cortex A15 DPLL is already locked, now unlocking...  
CortexA15_0: GEL Output:     Cortex A15 DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:     IVA DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:     IVA DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:     PER DPLL OPP 0 clock config in progress...
CortexA15_0: GEL Output:     PER DPLL already locked, now unlocking  
CortexA15_0: GEL Output:     PER DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:     CORE DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:     CORE DPLL OPP  already locked, now unlocking....  
CortexA15_0: GEL Output:     CORE DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:     ABE DPLL OPP 0 clock config in progress...
CortexA15_0: GEL Output:     ABE DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:     GMAC DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:     GMAC DPLL already locked, now unlocking....
CortexA15_0: GEL Output:     GMAC DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:     GPU DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:     GPU DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:     DSP DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:     DSP DPLL already locked, now unlocking....
CortexA15_0: GEL Output:     DSP DPLL OPP 0 is DONE!
CortexA15_0: GEL Output:     PCIE_REF DPLL OPP 0 clock config is in progress...
CortexA15_0: GEL Output:     PCIE_REF DPLL OPP 0 is DONE!
CortexA15_0: GEL Output: --->>> PRCM Clock Configuration for OPP 0 is DONE! <<<---
CortexA15_0: GEL Output: --->>> PRCM Configuration for all modules in progress... <<<---
CortexA15_0: GEL Output: --->>> PRCM Configuration for all modules is DONE! <<<---
CortexA15_0: GEL Output: --->>> DDR3 Initialization is in progress ... <<<---
CortexA15_0: GEL Output:     DDR DPLL clock config for 532MHz is in progress...
CortexA15_0: GEL Output:     DDR DPLL already locked, now unlocking....
CortexA15_0: GEL Output:     DDR DPLL clock config for 532MHz is in DONE!
CortexA15_0: Trouble Writing Memory Block at 0x4c000014 on Page 0 of Length 0x4: (Error -1141 @ 0x3D58) Device is not responding to the request. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 6.0.83.1)
CortexA15_0: GEL: Error while executing OnTargetConnect(): Target failed to write 0x4C000014
    at *((unsigned int *) (base_addr+0x14U))=(unsigned int) SDRAM_REF_CTRL [AM572x_ddr_config.gel:4]
    at EMIF_Config(0x4c000000U, 1U, 0U) [AM572x_ddr_config.gel:1007]
    at AM572x_DDR3_532MHz_Config() [AM572x_startup_common.gel:93]
    at AM57xx_EVM_Initialization(0) [gpevm_am572x.gel:54]
    at OnTargetConnect()

This is one of the errors I get, Sometimes it fails even at the beginning  (it fails to read the ID code - even in this sequence this happens). So the behaviour is similar to the one I experience with my initialization I realized with our software/framework. In fact it is even almost identical because my init fails when the  EMIF_SDRAM_REFRESH_CONTROL register is written. The access to this register seems to cause the Error Message which I receive in CCS 6.1.2.
Additional information I got from the customer is that they use Fly-By-topology not T-topology in their layout.

Peter

Peter,

When you say that you got a new board from the customer, is this a customer board or a GPEVM containing AM5728 PG2.0?

Tom

This is a customer board - perhaps you can explain what PG2.0 means (silcon revision maybe) ?


Peter

Peter,

Yes, PG2.0 (also written as ES2.0) is the latest silicon version.  It has only been available for a few months.  We are planning to launch it TMS in the next few weeks.

Do you see any issues with the same GEL file when executed on a PG2.0 GPEVM board?  The GEL is targeted for that platform.

Tom

Hello again,

I think I have the reason why it isn't working as expected.
so I programmed the eMMC with a random file (first 4MB) -> now the access to the RAM works.
Bottom line is:
- the software on the eMMC does something which neither our init nor the init of the CCS 6.1.2 with XDS100 is able to overcome.So this is really acustom problem.

I cannot test with PG2.0 GPEVM because I have none. TI gives this only to regular customers I think (under NDA) ?


Peter

What are the markings on the part (if you can see them -- there's a heat sink on the EVMs)?  In particular, I'm interested in the letters that follow AM5728.  Does it say AM5728ABC, AM5728AABC, or AM5728BABC?

Peter Haake said:

CortexA15_0: GEL Output: --->>> WARNING: UNKNOWN DEVICE ID (0x00000000), PLEASE UPDATE GEL FILES !!!! <<<---

This appears to be the upper nibble of 0x4AE0C204.  I would interpret from this that you're actually using PG1.0 silicon.  Besides the part marking, perhaps you could simply connect and read register 0x4AE0C204.

XAM5728BABCXE, that is the marking.

DIE_ID_PNI -> 0x3cba0200
ID_CODE -> 0x2b99002f
Both read with our software.

That's definitely 2.0 silicon. Odd that the line I mentioned printed out 0x00000000. You may want to see if you have the latest Sitara gel files:

processors.wiki.ti.com/.../Device_support_files