• State TI Thinks Resolved
  • Locked Locked
  • Replies 27 replies
  • Answers 2 answers
  • Subscribers 101 subscribers
  • Views 1010 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TDA4VM: TDA4 DDR Board_DDRInit FAIL

zhang zhengyang
Prodigy 120 points
Part Number: TDA4VM
Other Parts Discussed in Thread: DRA821,

In the offline hardware testing of the factory, there is a problem of TDA4 DDR initialization failure,
especially in the case of repeated warm resets on a single ECU with a higher probability.
by debug, the software enters a while loop at Board_DDRInit function.
We used hynix's DDR H54G56BYYPX046(4G)
Please analyze the reasons based on the following two cases and determine if it is necessary to modify board_ddrRegInit.h? See attachment.

case1：
Board_DDRChangeFreqAck

while(regVal == 0x0)
{
regVal = HW_RD_REG32(BOARD_DDR_FSP_CLKCHNG_REQ_ADDR) & 0x80;
BOARD_DEBUG_LOG("Reg Value: %d \n", regVal);
}

case2：
LPDDR4_PollPhyIndepIrq
LPDDR4_CheckPhyIndepInterrupt

/* Loop until irqStatus found to be 1 or if value of 'result' !=CDN_EOK */
do {
if (++timeout == delay) {
result = CDN_EIO;
break;
}
CPS_DelayNs(10000000U);
result = LPDDR4_CheckPhyIndepInterrupt(pD, irqBit, &irqStatus);
} while ((irqStatus == false) && (result == (uint32_t)CDN_EOK));

  • 0 in reply to zhang zhengyang
    TI__Mastermind 34450 points

    Hi Zhang,

    Is this a new board design / initial board bring-up or existing system that has just begin to fail? How many boards are failing (raw count and percentage)?

    After the failure occurs, can you run the attached binary (from the R5 core) and provide the output? The binary loads through Code Composer Studio.

    1680.tda4x_lp4_debug.zip

    Thanks,
    Kevin

  • 0 in reply to Kevin S
    Prodigy 120 points

    hi，Kevin.

    Perform the same 100 times soft reset tests on the same ECU and software version, may fail 3-4 times.

    I cant run the binary, cause our ECU are special designed.

    here are register information about DDR , stored when   software stopped at  

    case1：
    Board_DDRChangeFreqAck

    while(regVal == 0x0)
    {
    regVal = HW_RD_REG32(BOARD_DDR_FSP_CLKCHNG_REQ_ADDR) & 0x80;
    BOARD_DEBUG_LOG("Reg Value: %d \n", regVal);
    }

    please check the register and give some advice ,thank youTDA4_DDR.xlsx

  • 0 in reply to zhang zhengyang
    Prodigy 120 points

    During soft reset of soc ，the DDR0_RESETn will be pull down,  then pull up

    But sometimes DDR0_RESETn wont pull down, so the DDR_init failed .

     

    Explain why?

  • 0 in reply to zhang zhengyang
    TI__Expert 6951 points

    Hello Kevin

          this is UAES/VDC project issue, this project is very close to SOP, please handle this case as high priority, 

    Thanks

        Semon

  • 0 in reply to Semon Zhang
    TI__Mastermind 34450 points

    Hi Zhang,

    Can you provide exact sequence being used to issue soft reset?

    Hi Semon,

    Understand, I will send you private email.

    Regards,
    Kevin

  • 0 in reply to Kevin S
    Prodigy 120 points

    SOC TDA4 +  PMIC TPS6594 + DDR  H54G56BYYPX046(4G)      when reset source detected , SOC call function Sciclient_pmDeviceReset(RESETM_TIMEOUT); ,then  TDA4 restarted , but DDR reset pin sometimes failed to pull down .

    we did not set  PMIC TPS6594.

  • 0 in reply to zhang zhengyang
    TI__Expert 6951 points

    Hello Zhengyang

         according to your words, it can occur on DRA821 too, I verified it on EVM with SDK 8.6, with attached patch.

          not be able to re-produce it on 821 EVM with over 200 times test.

         see log.

    --------------------------

    Frequency Change type 1 request from Controller
    Reg Value: 0
    Reg Value: 128
    Frequency Change type 0 request from Controller
    Reg Value: 0
    Reg Value: 128
    Frequency Change type 1 request from Controller
    Reg Value: 0
    Reg Value: 128
    Frequency Change type 2 request from Controller
    Reg Value: 0
    Reg Value: 128
    Frequency Change type 1 request from Controller
    Reg Value: 0
    Reg Value: 128
    Frequency Change type 2 request from Controller
    Reg Value: 0
    Reg Value: 128
    Frequency Change type 1 request from Controller
    Reg Value: 0
    Reg Value: 128
    Frequency Change type 2 request from Controller
    --->>> Frequency Change request handshake is completed... <<<---
    LPDDR4_Start: PASS

    --------------------------------

    ddr-reset-nok.patch

    Regards

        Semon

  • 0 in reply to Semon Zhang
    TI__Expert 6951 points

    Hello Zhengyang

         test on 821 EVM with SDK 8.0, can't reproduce it either

    -------------------

    SD Boot - File open fails
    SBL Revision: 01.00.10.01 (Nov 21 2023 - 16:40:05)
    TIFS ver: 21.5.0--v2021.05 (Terrific Llam
    Board_DDRProbe: PASS
    calling Board_DDRInitDrv...
    Board_DDRInitDrv: PASS
    calling LPDDR4_Start: start
    0-infoType 1
    1-infoType 1
    --->>> LPDDR4 Initialization is in progress ... <<<---
    Reg Value: 128
    Frequency Change type 1 request from Controller
    Reg Value: 0
    Reg Value: 128
    Frequency Change type 0 request from Controller
    Reg Value: 0
    Reg Value: 128
    Frequency Change type 1 request from Controller
    Reg Value: 0
    Reg Value: 128
    Frequency Change type 0 request from Controller
    Reg Value: 0
    Reg Value: 128
    Frequency Change type 1 request from Controller
    Reg Value: 0
    Reg Value: 128
    Frequency Change type 2 request from Controller
    Reg Value: 0
    Reg Value: 128
    Frequency Change type 1 request from Controller
    Reg Value: 0
    Reg Value: 128
    Frequency Change type 2 request from Controller
    Reg Value: 0
    Reg Value: 128
    Frequency Change type 1 request from Controller
    Reg Value: 0
    Reg Value: 128
    Frequency Change type 2 request from Controller
    --->>> Frequency Change request handshake is completed... <<<---
    LPDDR4_Start: PASS

    ---------------------------------

    Regards

       Semon

  • 0 in reply to zhang zhengyang
    TI__Expert 6951 points
    zhang zhengyang said:

    During soft reset of soc ，the DDR0_RESETn will be pull down,  then pull up

    But sometimes DDR0_RESETn wont pull down, so the DDR_init failed .

     

    Hi Zhengyang

         can you confirm for each DDR_init failed, DDR0_RESETn wont pull down??

    Regards

       Semon

  • 0 in reply to Semon Zhang
    Prodigy 120 points

    Yes, this has been measured with an oscilloscope.

    The current important thing is to analyze why RESET has not been pulled down.
    whether the evaluation board can reproduce it is not important.

  • 0 in reply to Semon Zhang
    TI__Mastermind 34450 points

    Hi Zhang,

    How is the DDR_RET pin connected on the board? Can you also probe this signal to see if it is being driven high?

    Can you provide the portion of the schematic which illustrates the DDR_RESETn connections?

    Regards,
    Kevin

  • 0 in reply to Kevin S
    TI__Mastermind 34450 points

    Hi Zhang,

    In addition, do you see failures if you power cycle your board / system completely  (as opposed to calling function Sciclient_pmDeviceReset(RESETM_TIMEOUT))?

    Thanks,
    Kevin

  • 0 in reply to Kevin S
    TI__Expert 6951 points

    Hello Kevin

         the patch in the refered e2e works in this case.

    https://e2e.ti.com/support/processors-group/processors---internal/f/processors---internal-forum/1249128/tda4vm-there-is-a-ddr-reinitialize-case-need-your-support-with-high-priority?tisearch=e2e-sitesearch&keymatch=ddr%20reinitialize#

    ------------------------------------

    +        *(volatile unsigned int*)(0x400A3C) = (*(volatile unsigned int*)(0x400A3C) & 0xFFFFFF00) | 0x1;
    +        *(volatile unsigned int*)(0x400120) = 0x1;
    +
    +        while(*(volatile unsigned int*)(0x400128) != 0);
    +
    +        *(volatile unsigned int*)(0x400A38) = (*(volatile unsigned int*)(0x400A38) & 0xFFFFFF00) | 0x1;
    +        *(volatile unsigned int*)(0x400120) = 0x1;
    +
    +        while(*(volatile unsigned int*)(0x400128) != 0);
    +
    +        *(volatile unsigned int*)(0x400A3C) = (*(volatile unsigned int*)(0x400A3C) & 0xFFFFFF00) | 0x3;
    +        *(volatile unsigned int*)(0x400120) = 0x1;
    +
    +        while(*(volatile unsigned int*)(0x400128) != 0);
    +
    +        *(volatile unsigned int*)(0x400A38) = (*(volatile unsigned int*)(0x400A38) & 0xFFFFFF00) | 0x3;
    +        *(volatile unsigned int*)(0x400120) = 0x1;
    +
    +        while(*(volatile unsigned int*)(0x400128) != 0);

    --------------------------------------------------------------------------------

    for DRA821 has the same issue but much harder to re-produce it.

    want to know whether this patch can also be applied to DRA821?

    if need to change the address when applied to DRA821?

    Thanks 

       Semon 

  • 0 in reply to Semon Zhang
    TI__Mastermind 34450 points

    Hi Semon,

    I previously sent this via email but since this ticket was still open also adding here. Is this issue now resolved?

    Semon Zhang said:
    want to know whether this patch can also be applied to DRA821?

    Yes, addressing of PSC0 registers should be the same according to latest TRMs. Base address of both devices is 0x40 0000, and the LPSC index of LPSC_EMIF_DATA and LPSC_EMIF_CFG should be the same  between TDA4VM and DRA821 as well (14/15 respectively).

    Regards,
    Kevin

  • 0 in reply to Kevin S
    Prodigy 120 points

    (14/15 respectively)    what does that mean?

  • 0 in reply to zhang zhengyang
    TI__Mastermind 34450 points

    Hi Zhang,

    zhang zhengyang said:
    (14/15 respectively)    what does that mean?

    Those are the LPSC index values of LPSC_EMIF_DATA and LPSC_EMIF_CFG (see table 5-1345 in section 5.2.2.3.1.3.2 PSC0 Device-Specific Information of the DRA821 TRM, revision B Oct 2023).

    If you look at table 5-1519 PSC0 Registers, there are a group of registers whose address are determined by a formula. For instance, the module control register address is 0x0040 0A00 + formula, where the formula is 4 * LPSC index.

    Thus for LPSC_EMIF_DATA, the register address is 0x0040 0A00 + (4 * 14) = 0x0040 0A38 (which is used in the code snippet in this thread)

    Regards,
    Kevin

  • 0 in reply to Kevin S
    TI__Expert 6951 points
    Kevin S said:
    I previously sent this via email but since this ticket was still open also adding here. Is this issue now resolved?

    Hi Kevin

         this patch works for DRA821 and TDA4VM, the issue is fixed, 

         but whether there has some root cause analysis for this issue, seems this issue occurs on many projects

    Thanks

        Semon

  • 0 in reply to Semon Zhang
    TI__Expert 6951 points
    Semon Zhang said:
    +        *(volatile unsigned int*)(0x400A3C) = (*(volatile unsigned int*)(0x400A3C) & 0xFFFFFF00) | 0x1;
    +        *(volatile unsigned int*)(0x400120) = 0x1;
    +
    +        while(*(volatile unsigned int*)(0x400128) != 0);
    +
    +        *(volatile unsigned int*)(0x400A38) = (*(volatile unsigned int*)(0x400A38) & 0xFFFFFF00) | 0x1;
    +        *(volatile unsigned int*)(0x400120) = 0x1;
    +
    +        while(*(volatile unsigned int*)(0x400128) != 0);
    +
    +        *(volatile unsigned int*)(0x400A3C) = (*(volatile unsigned int*)(0x400A3C) & 0xFFFFFF00) | 0x3;
    +        *(volatile unsigned int*)(0x400120) = 0x1;
    +
    +        while(*(volatile unsigned int*)(0x400128) != 0);
    +
    +        *(volatile unsigned int*)(0x400A38) = (*(volatile unsigned int*)(0x400A38) & 0xFFFFFF00) | 0x3;
    +        *(volatile unsigned int*)(0x400120) = 0x1;
    +
    +        while(*(volatile unsigned int*)(0x400128) != 0);

    Hello Kevin

         according the test result in customer hardware platform, sometimes the above patch can cause the watchdog timeout, for there has "while loop" in the patch,

         is it possible to improve this patch for the watchdog issue?

    Thanks

        Semon

  • 0
    TI__Expert 6951 points

    Hello Zhengyang

        I test the executing time for this patch, see the test capture

    it's about 5 us, seems not be able to cause watchdog timeout

    Regards

       Semon

  • 0
    TI__Expert 6951 points

    hello Kevin

         in customer factory, there has 110 boards, one board has this issue,  warm reset can't boot up, and hung in DDR 

    static void Board_DDRChangeFreqAck(void)
    {
    .......
     for(counter = 0; counter < gBoardDdrCfgPrms[gBoardDdrCfgVer].fhsCnt; counter++)
        {
            /* wait for freq change request */
            regVal = HW_RD_REG32(BOARD_DDR_FSP_CLKCHNG_REQ_ADDR) & 0x80;
            BOARD_DEBUG_LOG("Reg Value: %d \n", regVal);

            while(regVal == 0x0) // HUNG here
            {
                regVal = HW_RD_REG32(BOARD_DDR_FSP_CLKCHNG_REQ_ADDR) & 0x80;
                BOARD_DEBUG_LOG("Reg Value: %d \n", regVal);
            }

            reqType = HW_RD_REG32(BOARD_DDR_FSP_CLKCHNG_REQ_ADDR) & 0x03;
            BOARD_DEBUG_LOG("Frequency Change type %d request from Controller \n", reqType);

            if(reqType == 1)
            {
                Board_DDRSetPLLClock(gBoardDdrCfgPrms[gBoardDdrCfgVer].frequency1);
            }
    }
    test following signal, sometimes the board can't send out the DDR0_RESETn SIGNAL to DDR, which cause issue happen
    please help give suggestion how to make DDRSS send out stable RESETn signal in warm reset operation
    Thanks
       Semon
  • 0 in reply to Semon Zhang
    TI__Expert 6951 points

    update the status of this case:

         the DDR RESET_n signal can pull down then pull up after warm reset, it is caused by the hardware design, there is a capacitor connected to this pin,

    after remove this capasitor, RESET_n can capture the correct signal when warm reset the board,

         but the DDR INITIALIZATION failed occasionally yet.   

         please give suggestion how to debug it

    Thanks

       Semon

  • 0 in reply to Semon Zhang
    Prodigy 120 points

    In the offline hardware testing of the factory, there is a problem of TDA4 DDR initialization failure,

    especially in the case of repeated warm resets on a single ECU with a higher probability.

    by debug, the software enters a while loop at Board_DDRInit function.

    We used hynix's DDR   H54G56BYYPX046(4G)

    Please analyze the reasons based on the following two cases and determine if it is necessary to modify board_ddrRegInit.h? See attachment.

     

    case1：

    Board_DDRChangeFreqAck

     

            while(regVal == 0x0)

            {

                regVal = HW_RD_REG32(BOARD_DDR_FSP_CLKCHNG_REQ_ADDR) & 0x80;

                BOARD_DEBUG_LOG("Reg Value: %d \n", regVal);

            }

     

     

    case2：

    LPDDR4_PollPhyIndepIrq

    LPDDR4_CheckPhyIndepInterrupt

     

        /* Loop until irqStatus found to be 1 or if value of 'result' !=CDN_EOK */

        do {

            if (++timeout == delay) {

                result = CDN_EIO;

                break;

            }

            CPS_DelayNs(10000000U);

            result = LPDDR4_CheckPhyIndepInterrupt(pD, irqBit, &irqStatus);

        } while ((irqStatus == false) && (result == (uint32_t)CDN_EOK));

  • 0 in reply to Kevin S
    TI__Expert 6951 points

    upload the hardware design doc and DDR configuration file for this VDC project

    VCP2.1 TDA4 A&B&DDR.pdf

    VCP2.1 DDR layout.xlsx

    2330.H54G56BYYPX046-2100.xlsm

  • 0 in reply to Semon Zhang
    TI__Expert 6951 points

    upload the CCS DDR init log for this issue when DDR can't boot up

    ddr-init-failure-ccs-log-1.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    [MCU_Cortex_R5_0] Training Results; Frequency 0; CS 0
    PHY Vref Training:
    DQ Lane 0 Vref Mode: 0x7 Vref Sel: 0x2b
    DQ Lane 1 Vref Mode: 0x7 Vref Sel: 0x2b
    DQ Lane 2 Vref Mode: 0x7 Vref Sel: 0x2b
    DQ Lane 3 Vref Mode: 0x7 Vref Sel: 0x2b
    ACC Vref Control: 0x7ab
    CA Training:
    LP4 CA Programmed Delays:
    CA Bit 0 delay: 445
    CA Bit 1 delay: 414
    CA Bit 2 delay: 45b
    CA Bit 3 delay: 425
    CA Bit 4 delay: 454
    CA Bit 5 delay: 439
    Write Leveling:
    DQ Lane 0 WRDQS: 0x164
    DQ Lane 1 WRDQS: 0x194
    DQ Lane 2 WRDQS: 0x80
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX