Uploaded image for project: 'Embedded Software & Tools'
  1. Embedded Software & Tools
  2. EXT_EP-11855

OSPI Tuning algorithm has incorrect logic while searching secondary Rx high point

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: High High
    • PDK
    • PDK-14321
    • Hide
      PROCESSOR_SDK_09.02.00
      PROCESSOR_SDK_09.01.00
      Show
      PROCESSOR_SDK_09.02.00 PROCESSOR_SDK_09.01.00
    • PROCESSOR_SDK_10.00.00
    • Hide
      j721e-evm
      j7200-evm
      j721s2-evm
      j784s4-evm
      Show
      j721e-evm j7200-evm j721s2-evm j784s4-evm

      Description

      In the highlighted lines below, the rdDelay value will cause the if-check to always pass, meaning the 'break' statement will always be hit and the else-clause will never be run.

      searchPoint.rdDelay = PHY_DDR_TUNE_RD_DELAY_START;
      do
      {
      searchPoint.rxDLL = RX_DLL_HIGH_SEARCH_START;
      ...
      if((tempSearchPoint.rxDLL != PHY_DDR_TUNE_DLL_MAX)||
      (searchPoint.rdDelay == PHY_DDR_TUNE_RD_DELAY_START))

      { break; }

      else

      { searchPoint.rdDelay--; }

      }while(...)

      Resolution
      By starting the search from `read delay end`
      and breaking from search either if we successfully found Secondary Rx High or
      `current read delay` becomes `read delay start`.

      Root Cause
      The root cause of this issue is we are starting the loop from
      `read delay start` instead of starting from `read delay end` and breaks
      from loop if `current read delay` is `read delay start`.

            syncuser TI User
            syncuser TI User
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: