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.

DRA829V: DDRSS Configuration fails with timeout in CCS

Part Number: DRA829V
Other Parts Discussed in Thread: TDA4VM,

Hello,

I'm trying to debug with CCS 10.2 on the Jacinto processor. I use the J721E RTOS-SDK version 07.03.00.07 under Windows 10.

So far, debugging worked well on the EVM with the TDA4VM.

Now we have our own custom board with the DRA829V instead of the TDA4VM, and with a different DDR-SDRAM (we use MT53E256M32D2, EVM has MT53D1024M32D4DT, both from Micron).

When I try to debug on our custom board, the CCS debug script stops during DDR configuration with the following output:

Java script console output:

js:> loadJSFile("J:/ti/drv/sciclient/tools/ccsLoadDmsc/j721e/launch.js")
Connecting to DMSC_Cortex_M3_0!
Fill R5F ATCM memory...
Writing While(1) for R5F
Loading DMSC Firmware ... J:/ti/drv/sciclient/soc/sysfw/binaries/ti-fs-firmware-j721e-gp.bin
DMSC Firmware Load Done...
DMSC Firmware run starting now...
Connecting to MCU Cortex_R5_0!
WKUP Boot Mode is 56
Main Boot Mode is 17
Running the board configuration initialization from R5!
Running the DDR configuration... Wait till it completes!
Error evaluating "J7ES_LPDDR4_Config_Late()": Timed out after 200000ms (J:\ti\drv\sciclient\tools\ccsLoadDmsc\j721e\launch.js#157)
js:>

GEL console output:

[...]
DMSC_Cortex_M3_0: GEL Output: Powering up all PSC power domains done!
DMSC_Cortex_M3_0: GEL Output: Configuring drive strength.
DMSC_Cortex_M3_0: GEL Output: First, unlock the MMRs.
DMSC_Cortex_M3_0: GEL Output: Unlocked MMRs.
DMSC_Cortex_M3_0: GEL Output: Configuring horizontal drive strength.
DMSC_Cortex_M3_0: GEL Output: Horizontal drive strength configured.
DMSC_Cortex_M3_0: GEL Output: Configuring vertical drive strength.
DMSC_Cortex_M3_0: GEL Output: Vertical drive strength configured.
DMSC_Cortex_M3_0: GEL Output: LVCMOS drive strength configured to 0xD
DMSC_Cortex_M3_0: GEL Output: --->>> LPDDR4 Initialization is in progress ... <<<---
DMSC_Cortex_M3_0: GEL Output: Setting DDR PLL to 20MHz/19.2MHz on silicon (bypass)
DMSC_Cortex_M3_0: GEL Output: Set PLL to external bypass (20MHz/19.2MHz on SVB/EVM).
DMSC_Cortex_M3_0: GEL Output: --->>> DDR controller programming in progress.. <<<---
DMSC_Cortex_M3_0: GEL Output: --->>> DDR controller programming completed... <<<---
DMSC_Cortex_M3_0: GEL Output: --->>> DDR PI programming in progress.. <<<---
DMSC_Cortex_M3_0: GEL Output: --->>> DDR PI programming completed... <<<---
DMSC_Cortex_M3_0: GEL Output: --->>> DDR PHY Data Slice 0 programming in progress.. <<<---
DMSC_Cortex_M3_0: GEL Output: --->>> DDR PHY Data Slice 0 programming completed... <<<---
DMSC_Cortex_M3_0: GEL Output: --->>> DDR PHY Data Slice 1 programming in progress.. <<<---
DMSC_Cortex_M3_0: GEL Output: --->>> DDR PHY Data Slice 1 programming completed... <<<---
DMSC_Cortex_M3_0: GEL Output: --->>> DDR PHY Data Slice 2 programming in progress.. <<<---
DMSC_Cortex_M3_0: GEL Output: --->>> DDR PHY Data Slice 2 programming completed... <<<---
DMSC_Cortex_M3_0: GEL Output: --->>> DDR PHY Data Slice 3 programming in progress.. <<<---
DMSC_Cortex_M3_0: GEL Output: --->>> DDR PHY Data Slice 3 programming completed... <<<---
DMSC_Cortex_M3_0: GEL Output: --->>> DDR PHY Address slice 0 programming in progress.. <<<---
DMSC_Cortex_M3_0: GEL Output: --->>> DDR PHY Address Slice 0 programming completed... <<<---
DMSC_Cortex_M3_0: GEL Output: --->>> DDR PHY programming in progress.. <<<---
DMSC_Cortex_M3_0: GEL Output: --->>> DDR PHY programming completed... <<<---
DMSC_Cortex_M3_0: GEL Output: --->>> DDR PI initialization started... <<<---
DMSC_Cortex_M3_0: GEL Output: --->>> DDR Controller initialization started... <<<---
DMSC_Cortex_M3_0: GEL Output: --->>> Waiting for frequency change requests ... <<<---
DMSC_Cortex_M3_0: GEL Output: Frequency change request type 1 received from controller
DMSC_Cortex_M3_0: GEL Output: Setting DDR PLL + HSDIV to 933MHz
DMSC_Cortex_M3_0: GEL Output: DDR PLL Calibration Control MMR value: 0x80170000
DMSC_Cortex_M3_0: GEL Output: DDR PLL Calibration Control MMR value: 0x800001CA
DMSC_Cortex_M3_0: GEL Output: DDR PLL + HSDIV set to 933MHz.

Until this point, the GEL output is the same on our board and on the EVM. On our custom board, the output stops here, while on the EVM, several more "Frequency Change Requests" occur before the initialization is completed successfully.

Because of the different memory device, I downloaded the DDRSS config tool (Jacinto7_DDRSS_RegConfigTool.xlsm) and checked all parameters against the data sheet. Some where slightly different, leading to a different GEL DDRSS config file. However, the behavior is still the same. I also tried different DDR memory frequencies. I could see that the PLL is then set to a different frequency (so the generated config was definitely used), but the error persists. 

When I look at the GEL script, it seems it is waiting for another Frequency Change Request issued by the DDRSS, which never comes.

Any ideas what could be the root cause here? Maybe there are any status bits to see why the DDRSS does not issue any more request? Or might this be caused by a difference between DRA829V and TDA4VM?

By the way, when I disable the DDRSS initialization in the debugger scripts, an application linked to the internal RAM can be loaded and runs properly, so it doesn't look like a general problem with debugging or with the processor on our custom board.

Regards

Thomas

  • A quick update:

    In the meantime I also tried to use the DDRSS configuration I created with the parameters of our device together with the EVM. Despite of the some differences in the timing parameters, the initialization still worked properly here. So it seems the difference in the parameters is not so critical. Maybe it has impact on the performance, but it definitely does not prevent the DDRSS controller from working (as it looks like on our board). I guess the root cause is somewhere else. Either I missed an important parameter, or we have some different problem.

    Could anybody help regarding the initialization sequence (e.g. some background about these frequency change requests, and how they are triggered)? In the documentation there is not much information about it.

  • Hi Thomas,

    One notable difference between the DRAM used on the EVM and in your custom system is the density and number or ranks.

    As a first step, can you confirm that you have configured

    • Parameter 9 ("DDR Density") on the "Config" tab to "4"
    • Parameter 10 ("Chip Selects / Ranks") on the "Config" tab to "1"

    Regarding the frequency changes, these mostly occur during the command bus training. The controller should start the DRAM initialization at a "boot frequency" to initialize the DRAM mode registers, then switches to a higher frequency to perform CA training. It then switches back to the boot frequency to update the DRAM MRs, before switching back to the higher frequency for normal operation. Several more changes occur depending on the number of ranks and frequency set points enabled. As an example, the expectation is that 10 frequency changes will occur with a 2-rank DRAM (using v0.5.0 of the config tool), whereas only 6 frequency changes should occur with a single-rank DRAM. 

    Regards,
    Kevin

  • Thank you for the explanation!

    The parameters you mentioned actually had a different setting in my configuration. I changed them and tried it again, but unfortunately the behavior is still the same.

    I can see that the parameter DDRSS_PLL_FHS_CNT in the gel file has changed from 10 to 6, but the DDRSS still seems to get stuck after the first change request.

    Just in case this helps, here the generated DDRSS configuration file.

    J7-DDR-EVM-LP4-3733.gel

  • After further investigation, it seems we found the root cause for the problem. On our hardware, two of the four chip select signals are not connected correctly to the DRAM device (DDR0_CSN1_0 and DDR0_CSN0_1 have been swapped compared to the EVM).

    So the question is now: is it possible to operate the DRAM just with one CS line (e.g. DDR0_CS0_0, which is connected correctly)? As it would only be an interim solution until the hardware is fixed, it would be acceptable if e.g. only half of the DRAM size would be available.

    In the config tool, neither the density nor the data bus width can be further reduced. So I guess if it's possible at all, some manual editing of the generated configuration will be required required. 

  • Hi,

    As an experiment, can you try the attached config?J7-DDR-EVM-LP4-3733_exp1.gel

    Thanks,
    Kevin

  • Yes, this one seems to work! The init-script runs to the end without errors. I can also load an application linked to DRAM and run it from there. In the memory browser I can see that the memory content is repeated after 512MByte, which was kind of expectable.

    Thank you very much for your support, this helped us very much!

    Btw., apart from the reduced memory size, are there any other caveats with the configuration you created?

    Best regards

    Thomas

  • Hi Thomas,

    >>are there any other caveats with the configuration you created?

    I wasn't sure what changes you may have made in terms of input parameters to the tool. 

    This file was generated using XLS version 0.6.0 (which should be released to ti.com very soon). I used this version as it has support for 16-bit bus width, which is required due to the hardware chip select issue you provided details on. The default inputs started with the TI EVM values, then the following modifications were made:

    • Config Tab --> System Config --> #5 changed from "55" to "50"
    • Config Tab --> System Config --> #7 changed from "2133" to "1866"
    • Config Tab --> System Config --> #8 changed from "32" to "16"
    • Config Tab --> System Config --> #9 changed from "8" to "4"
    • Config Tab --> System Config --> #10 changed from "2" to "1"
    • DRAMTiming Tab --> Read Latency (F1 / F2) changed from "36" to "32"
    • DRAMTiming Tab --> Write Latency (F1 / F2) changed from "18" to "16"
    • DRAMTiming Tab --> Write Recovery (F1 / F2) changed from "40" to "34"
    • DRAMTiming Tab --> tODTon (F1 / F2) changed from "8" to "6"
    • DRAMTiming Tab --> tODToff (F1 / F2) changed from "28" to "26"

    All other defaults were left as is.