This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM625: AM625 DDR4 Configuration with CCS 20.1.0 GEL Scripts

Part Number: AM625
Other Parts Discussed in Thread: SYSCONFIG,

Tool/software:

Hello,

I was able to configure successfully the SDRAM on our custom board with CCS 20.1.0, project-less debug session  running AM62B-P1 EVM gel scripts. However, these scripts configure the 2GB space for 16Gb x 16 chip used on the EVM, while our board is using one single rank 32Gb x 16 DDR4 chip.

I tried replacing the AM62x-DDR4-1600MTs.gel (located in C:\ti\ccs2010\ccs\ccs_base\emulation\gel\AM62x\AM62_DDRSS\si_configs) with one generated by the SysConfig DDR4 configuration tool for our 32Gb x 16 chip but it is not working. Is there anything else that needs to be changed?

The 32Gb x 16 DDR4 SDRAM chips are actually two 16Gb x 8 dies in the package so that I wanted to try setting the gel scripts for two 16Gb x 8 chips but couldn't find where the number of chips are set.

Thanks,

Kris

  • Hi Kris,

    can you send the .syscfg files and the GEL you used that were generated from the tool?

    Also, ensure you have the wrapper control register set correctly in ccs_base/emulation/gel/AM62x/AM62_DDRSS/AM62x_ddr_top.gel.  The 4GB setting should be uncommented, as shown below:

    //TI_set_DDR_size(0x000001AF); //for 512MB DDR
    //TI_set_DDR_size(0x000001EF); //for 2GB DDR
    TI_set_DDR_size(0x00000210); //for 4GB DDR
    //TI_set_DDR_size(0x00000231); //for 8GB DDR

    Regards,

    James

  • Hi James,

    So I use all the default files in the ccs_base/emulation/gel/AM62x directory as assigned by the selection of the AM62x_SK_EVM in the ccxml file.

    Interesting enough, the 4GB DDR line in the AM62x_ddr_top.gel was uncommented, even since these settings were for the AM62x EVM, which has 2GB of DDR4 SDRAM.

    Here is the sysconfig file that works for our custom board:

    /**
    * Import the modules used in this configuration.
    */
    const DDRSS = scripting.addModule("/DDRSS");

    /**
    * Write custom configuration values to the imported modules.
    */
    DDRSS.ddr4.$name = "sitara_ddr4_DDRSS_DDR40";
    DDRSS.ddr4.config_fsp0_MHz = 400;

    It is 16Gb x 16 single chip single rank at 400 MHz. Our board does not appear to work at 800 MHz.

    I use the output of this configuration, AM62x-DDRConfig.gel, rename it with the one used in the EVM scripts - AM62x-DDR4-1600MTs.gel - and run the project less configuration be connecting to the TIFS_0 core first and then to the A53_0 core next, which configures everything necessary.

    Then I run the Data_WrRd_test from AM62 DDRSS Memory debug/Data Tests script menu and the SDRAM appears to work.

    CortexA53_0: Starting WrRd Test 1: *wr32_ptr=i
    CortexA53_0: Starting WrRd Test 2: *wr32_ptr=~i

    If I increase the speed to 800 MHz or change the chip dencity from 16Gb to 32Gb the test returns error:

    CortexA53_0: Starting WrRd Test 1: *wr32_ptr=i
    CortexA53_0: Data verification failed at 0x0000000080000000 Expected = 0x00000000 Actual= 0x020003FF
    CortexA53_0: Data verification failed at 0x0000000080000004 Expected = 0x01010101 Actual= 0x04010202
    CortexA53_0: Starting WrRd Test 2: *wr32_ptr=~i
    CortexA53_0: Data verification failed at 0x0000000080000000 Expected = 0x030100FF Actual= 0x03FF00FF
    CortexA53_0: Data verification failed at 0x0000000080000004 Expected = 0x0100FFFE Actual= 0x01FEFF01
    CortexA53_0:
    !!!!! DDR Basic read/write test Failed !!!!

    Thanks,

    Kris

  • Hi Kris, 

    Sorry i'm on the hardware team and I'm unfamiliar with this portion of what you said:

    /**
    * Import the modules used in this configuration.
    */
    const DDRSS = scripting.addModule("/DDRSS");

    /**
    * Write custom configuration values to the imported modules.
    */
    DDRSS.ddr4.$name = "sitara_ddr4_DDRSS_DDR40";
    DDRSS.ddr4.config_fsp0_MHz = 400;

    The DDR driver in the GEL will get the frequency setting for the DDR from the GEL.  For DDR4, the upper portion of AM62x-DDRConfig.gel should look something like this:


    #define DDRSS_PLL_FHS_CNT 6
    #define DDRSS_PLL_FREQUENCY_1 400000000
    #define DDRSS_PLL_FREQUENCY_2 400000000

    The GELs uses this information to set the PLLs for the DDR.  Note that these are PLL frequencies, which will always be half of the memory clock frequency.  So the values above actually equate to 800MHz operation (ie 1600MTs).  

    I'm not sure what this line:

    DDRSS.ddr4.config_fsp0_MHz = 400;

    is doing, or if you even need it.  

    The 16Gb vs. 32Gb seems to be a different problem.  Can you send me the GEL file you generated.  Since it is 2 8bit dies, you would need to set the following in the tool:

    Data bus width: 8

    Density: 16Gb

    Chip Selects: 1

    Regards,

    James

  • Hi James,

    I have sent the content of the sysconfig file because I couldn't figure out how to attach file.

    By the way the tool sets the frequency of the DDR PLL source to half the I/O frequency. So for DDR4-1600, the I/O frequency is 800 MHz, but the AM625 PLL source frequency is set to 400 MHz. I saw an E2E article that was mentioning that the DDRSS peripheral has its own PLL, which doubles the input frequency.

    Just open the sysconfig DDR tool for AM625 and look at the gel file or any other file for that matter. If you look at the untitled.syscfg, you will see the lines I have sent you.

    However, setting the frequency is not the issue here. I mentioned it because we had to set it to 400 MHz (DDR4-800), instead of default 800 MHz (DDR4-1600), in order to get our DDR4 memory to work at all.

    My main problem is setting and understanding the correct settings for 32Gb x 16 SDRAM that we use.

    Like I mentioned before, this is a signle Miron chip (MT40A2G16TBB-062E:F), which is built with two 16Gb x 8 dice. It is a single rank (chip select) part.

    I guess the right setting for the sysconfig DDR tool is to set 32Gb x 16 size but it does not work for me.

    The setting in the DDR4 sysconfig tool are pretty simple. When I generate gel file with the following DDR4 parameters it works: (everything else is default)

    Memory Frequency (MHz) - 400
    Data Bus Width (per device) - 16
    Density (per device) (Gb) - 16
    Chip Selects / Ranks - 1

    If I change the Density (per device) (Gb)  to 32 our board DDR4 no longer works:

    Memory Frequency (MHz) - 400
    Data Bus Width (per device) - 16
    Density (per device) (Gb) - 32
    Chip Selects / Ranks - 1

    Below I describe my test setup, that uses CCS, JTAG, and gel scripts to configure and test the memory.

    I use the CCS 20.1.0 and I start projet-less debug session with the ccxml configuration file for the AM62x EVM. (The EVM ccxml configuration places gel scripts in the correct cores)

    I first connect to the SMS_CM4_0_TIFS_0 core, which configures on connect all required SoC internal components, like power domains, PLLs, etc.

    Then, I connect to the CortexA53_0 core, which configures on connect the DDR4 controller.

    Then I am running the script from "Scripts | AM62 DDRSS Memory debug | Data Tests | Data_WrRd_test", which passes the check with the first configuration gel file (16Gb x 16) and fails the second (32GB x 16).

    As I mentioned before, in order to use the DDR sysconfig settings I have generated, I rename the sysconfig generated file "AM62x-DDRConfig.gel" to "AM62x-DDR4-1600MTs.gel" and place it in the "C:\ti\ccs2010\ccs\ccs_base\emulation\gel\AM62x\AM62_DDRSS\si_configs" directory, which causes the configuration scripts to use my settings. (This is where the configuration gel scripts for the AM62x EVM are located.)

    PS.

    I tried to insert file using Google, Firefox, and IE on Windows 11 but when I get into the menu "Insert | Image/video/file" pop-up window from the bottom of the edit box where I am typing my response, I cannot insert a file from my computer. There must be something I am missing!

    Thanks,

    Kris

  • Hi Kris,

    if you are using the 2Gx16 device (ie, the TwinDie device), then under the hood, this is physically two x8 dies, so you should set your DataBusWidth = 8, with Density = 16Gb (there are two 16Gb dies in the package)

    This should get you to be able to access the full  4Gbyte of memory.

    PS

    The interface is weird.  If you see the greyed out "Upload" link, it is actually functional.  Hover over it and then browse for the file you want to upload.  

    Regards,

    James

  • Hi James,

    16Gb x 8 is only 2GB. Shouldn't somewhere be indicated that there are two (2) device 16Gb x 8, which would be 4GB?

    Thanks, the file upload work, just very tricky to figure out.

    Here are the sysconfig files in a zip file since the syste is not taking .syscfg type files. It includes:

    • 16Gbx16x400MHz.syscfg - this one works on our board but it is only 2GB
    • 32Gbx16x400MHz.syscfg - this one does not work but it is 4GB, which is what we have
    • 16Gbx8x400MHz.syscfg - this is what you suggested. This is 2GB only and while it matches the dice in the SDRAM part we use, it looks like the interface is only 8-bit. I would think that it needs information somewhere that there are (two 2) 16Gbx8 dice configured in 16-bit interface.

    Sysconfig-Files.zip

    Kris

  • Hi Kris, AM62x only supports 16-bit wide interface.  So the tool assumes that if you choose 8bit wide bus width, you will be using two dies to achieve a x16 wide bus.  This selection essentially distinguishes between using BG[1:0] signals (as in the case with 8bit devices) vs using BG0 (as in the case with 16bit devices)

    So is the 16Gbx8x400MHz.syscfg configuration functional?  Can you uniquely access all 4GB?  To check this, open up memory browser and write to 0x8000_0000 and 0x8_8000_0000 and ensure there is no aliasing.

    Regards,

    James

  • James,

    Thanks for the quick replay. I though I tested the x8 setup earlier without much success.

    I am currently in a EMC laboratory working on RF emissions and immunity testing but I will be back in the office tomorrow and I will let you know.

    Regards,

    Kris

  • Hi James,

    Today I was able to run our custom AM6254 board, that is using Micron MT40A2G16TBB-062E:F SDRAM - a dual 16Gbx8 dice part, with 16Gbx8 sysconfig configuration, which covered the entire 4GB range.

    I have not performed a complete memory space test but the 0x8000_0000 and 0x8_8000_0000 addresses do not show aliasing.

    Do you have any available GEL test scripts that may help with more thorough testing?

    Also I am currently running half the maximum DDR4 controller speed (400 MHz instead of 800 MHz), possibly due to signal integrity issues on our PCB. Can you suggest any test GEL scripts or other tools for debugging this issue?

    Thanks,

    Kris

  • Hi Kris,

    we don't have GEL test scripts (running GELs is too slow and wouldn't stress the interface anyway).  We do have a baremetal memtester binary which can be loaded into A53 and run.  This will perform stress tests of different patterns on the DDR interface.

    /cfs-file/__key/communityserver-discussions-components-files/791/3348.AM62X_5F00_DDR_5F00_MEMTESTER_5F00_A53.zip

    For the memory space test, we don't have any scripts specifically for this, but the manual test that you performed could be expanded as needed.  I don't think you need to do much more that a few manual checks across the memory region at specific boundaries (maybe just 0x80000000, 0xA0000000, 0xC0000000)

    Regards,

    James

  • Kris, we split that last question into a new thread: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1497557/re-am625-am625-ddr4-configuration-with-uboot

    we can continue debugging 400MHz vs 800MHz here after you get through that.

    Regards,

    James

  • Sounds good James,

    Kris

  • Kris, is there any followup here?

    Regards,

    James

  • Hi James,

    I run the binary and showed that the DDR4 memory is not running at 800MHz but have not been able to get any specific information about the problem.

    It appears that is some kind of PCB SI issue but it would be nice if we can drill a little bit deeper to help us look at more specific layout improvements.

  • Ok, seems the other thread got stuck a bit.  Let me see if i can follow up with Bin on Monday

    Regards,

    James