[参考译文] OSPI-AM243X：使用带千兆位设备闪存的 MCU-PLUS-SDK PHY 模式时、闪存驱动器有时会读取垃圾数据

尊敬的 Felix Heil：

最好的猜测是他们的曲线在这里和那里稍微偏移、并且算法不会从正确的末端开始。  我们有一些可以尝试的东西、将在计划的通话中讨论相同的内容。

一个导致调整失败的外部因素是温度(可能是？)。

此致、
Aakash

尊敬的 Aakash：

我将跟进一个错误的 phyGraph-Curve 并发送给您和 Anand 我们在会议上同意。 温度问题可能是一个原因、因为它不是在第一次上电时发生的、而是在器件已经有一定温度的情况下发生在第2次或第3次关断开启动作时。

此致

费利克斯

尊敬的 Felix Heil：

如前所述、如果您能够生成具有  OSPI_phyTuneGrapher 需要单独调用。 那么我们可能会获取一些数据。 此数据可用于绘制图形。 绘制图表后、我们可以找到 PHY 的最佳参数。 如果您对此有任何更新、请告知我们。

此致、
Aakash

嘿、Aakash、所以我实现了这个函数、想要再次赶上这个情况。

接地短路情况。 我认为我们需要考虑多种情况。

表明这个问题的第一批产品是使用外壳和灌封化合物以及最新的 Sitara hs-fs 衍生产品的新成品。 由于我们仍处于开发阶段、因此我们有多个阶段。 我现在有一个 PCBA 没有灌封与 GigaDevice FLASH 和 Sitara gp 是几个月前生产. 在这里、我无法重现问题。 我也试着去抚摸它,看看这是否会影响它,但它没有。

此外、并非所有最新生产的器件都出现了这种情况。 仅有少数几个。 我还要检查布局中的某些内容是否可能发生了更改。 但是、这似乎只有在我们收到的最新 Sitara 批处理中才会发生。 我回来时会提供更详细的信息、我还会尝试再次找到一个有故障的器件、我的最后一个器件在该过程中以某种方式损坏(我们需要刮擦它、可能有些元件已损坏)。

我想我下周会收到一台新器件、然后我会尝试重现问题并创建图表。

此致、

费利克斯

尊敬的 Felix：

在这方面、我已请求专家提供帮助。 他可以帮助你更详细地找到问题。

此致、
Aakash

尊敬的 Felix：  

您是否对该问题出现的新电路板数量以及其中多少块电路板有估计？ 此外、一旦您发现有故障的电路板、问题是 持续重现 还是只是间歇性发生？ 产品是在 GD 闪存启动时也出现问题、还是这是运行时独有的问题？  

如果您在原理图的修订版本之间有任何差异、敬请告知、与此同时、我将尝试查明 GP 和 FS 器件之间是否存在可能导致此行为的任何差异。 如果我们找出可能引起担忧的问题、我将更新问题。  

此致！

丹尼尔

Daniel、您好！

我与我们的同事进行了协调。 我们将尽快提供这些信息。

目前、75%的器件似乎都出现了问题。 此问题肯定是通过禁用 OSPI-PHY 来解决的。 我们的服务部门进行了检查。 这个问题在我的一块电路板上重现。 但是在某种意义上"持续"、每三到四次启动就会出现这种行为。

问题会发生在引导加载程序中、也会发生在应用程序中、因此请注意：在本例中、引导加载程序是一个单独的"应用程序"：引导加载程序使用了 OSPI-PHY。 因此、可能会说启动成功、但以下应用程序也会再次初始化 OSPI 并启用 OSPI-PHY。 此处、我们还注意到、启动时、文件系统无法正确读取数据、并运行到自定义断言 Us、当数据损坏时会发生这种情况。 因此、会发生一种情况(引导加载程序未成功从闪存读取正确数据)或另一种情况(应用程序闪存读取未成功)。

很遗憾、上述器件在打开时已损坏、因此我目前这里没有器件可供我现在重新生成。 我们目前正在打开另一个器件。 因此、我还将向您不断更新、并尽快提供开头提到的 Phy 图。

此致

费利克斯

尊敬的 Felix：  

感谢更新、我仍在努力找到关于器件类型的信息、到目前为止、GD 和 FS 器件之间似乎没有任何产品可以导致此问题。

此致！

丹尼尔

e2e.ti.com/.../ISSI_5F00_25WX256_5F00_working_5F00_02_5F00_out.txte2e.ti.com/.../GigaDevice_5F00_25LX256E_5F00_working_5F00_02_5F00_out.txt
尚未重现将 PHY 与 OSPI 配合使用的问题、但可以记录 ISSI 器件(正常工作)和 GigaDevice 器件(有时有问题)的 phyTuneGraph。 两个图形都是在室温下使用200MHz 时钟捕获的正在运行的闪存器件。 您能看到为什么 GigaDevice 闪存可能由于错误的 DDR 调优而启动吗？

尊敬的 Robert：

从图中可以看到、RD Delay 似乎已设置为2。 根据一些研究、将器件切换到 HSF 很可能对之前观察到的行为没有影响。 几个方面：

• 那么、您无法再访问最初发生故障的电路板了吗？ 一个有趣的实验是在上面放置一个 HSFS 器件并检查其功能
• 您当前的设置是什么？ 您是否获得了具有 HSFS 器件和 GigaDevice 闪存的新电路板、并且目前正在对此进行测试？  
• 您是否可以尝试将速度降低到166MHz、看看新设置中是否再次出现问题？  

此致！

丹尼尔

尊敬的 Felix：

该主题已解锁。 请回答 Daniel 的问题。

此致、

明

我们的想法是现在将 DDR 调优算法更改为具有快速修复运行时的以下解决方案：

/*
 *
  The algorithm here is used to find the must stabble settings for OSPI DRR operation.
  
  Normally Map of working settings (X=hit, 0=miss):
  _________________________________________ RX_Dll
  |0000000000000000000000000000000000000000
  |0000000000000000000000000000000000000000
  |00000XXXXXXXXXXXX00000000000000000000000
  |0000XXXXXXXXXXXXX00000000000000000000000
  |000XXXXXXXXXXXXXX00000000000000000000000
  |00XXXXXXXXXXXXXXX00000000000000000000000
  |00XXXXXXXXXXXXXXX00000000000000000000000
  |00XXXXXXXXXXXXXXX00000000000000000000000
  |00XXXXXXXXXXXXXXX00000000000000000000000
  |00XXXXXXXXXXXXXXX00000000000000000000000
  |00XXXXXXXXXXXXXXX00000000000000000000000
  |0000000000000000000000000000000000000000
  |0000000000000000000000000000000000000000
  |0000000000000000000000000000000000000000
  |0000000000000000000000000000000000000000
  |0000000000000000000000000000000000000000
  |0000000000000000000000000000000000000000
  TX_Dll

  The algorithm has the target to find the middle of the hit region, 
  with as least hit/miss tests than possible. The idea is to test 
  different txDll and rxDll values in a wide mesh.
   _________________________________________ RX_Dll
  |
  |      0   0   0   0   0
  |
  |      X   X   X   0   0
  |
  |      X   X   X   0   0
  |
  |      X   X   X   0   0
  |
  |      X   X   X   0   0
  |
  |      0   0   0   0   0
  |
  |      0   0   0   0   0
  |
  |
  |
  TX_Dll
*/
int32_t OSPI_phyFindOTP_Balluff(OSPI_Handle handle, uint32_t flashOffset, OSPI_PhyConfig *otp)
{
    int32_t status = SystemP_SUCCESS;
    OSPI_PhyConfig searchPoints[] = {{.rdDelay = 2, .rxDLL=0, .txDLL=0},
                                   {.rdDelay = 2, .rxDLL=0, .txDLL=0},
                                   {.rdDelay = 2, .rxDLL=0, .txDLL=0}};

    uint32_t rxWeight = 0;
    uint32_t txWeight = 0;
    uint32_t hitCounter = 0;

    for(int rx = gPhyTuneBalluffParams.rxStart; 
            rx < gPhyTuneBalluffParams.rxEnd; 
            rx += gPhyTuneBalluffParams.rxStep)
    {
        for(int tx = gPhyTuneBalluffParams.txStart; 
                    tx < gPhyTuneBalluffParams.txEnd; 
                    tx += gPhyTuneBalluffParams.txStep)
        {
            searchPoints[0].rxDLL = rx;
            searchPoints[0].txDLL = tx;
            OSPI_phySetRdDelayTxRxDLL(handle, &(searchPoints[0]));
            status = OSPI_phyReadAttackVector(handle, flashOffset);
            if(status == SystemP_SUCCESS)
            {
                rxWeight += rx;
                txWeight += tx;
                hitCounter++;
            }
        }
    }

    status = SystemP_FAILURE;
    if(rxWeight != 0 && rxWeight != 0)
    {
        otp->rdDelay = searchPoints[0].rdDelay;
        otp->rxDLL = rxWeight / hitCounter;
        otp->txDLL = txWeight / hitCounter;
        status = SystemP_SUCCESS;

        // test target spot 
        searchPoints[0].rxDLL = otp->rxDLL;   
        searchPoints[0].txDLL = otp->txDLL;
        // test target spot with lower safety distance
        searchPoints[1].rxDLL = otp->rxDLL - gPhyTuneBalluffParams.rxSafetyDistance;   
        searchPoints[1].txDLL = otp->txDLL - gPhyTuneBalluffParams.txSafetyDistance;
        // test target spot with higher safety distance
        searchPoints[2].rxDLL = otp->rxDLL + gPhyTuneBalluffParams.rxSafetyDistance;   
        searchPoints[2].txDLL = otp->txDLL + gPhyTuneBalluffParams.txSafetyDistance;

        for(uint32_t i = 0; 
            status == SystemP_SUCCESS && i < sizeof(searchPoints)/sizeof(searchPoints[0]); 
            i++)
        {
            OSPI_phySetRdDelayTxRxDLL(handle, &(searchPoints[i]));
            status = OSPI_phyReadAttackVector(handle, flashOffset);
        }
    }
    
    if(status != SystemP_SUCCESS)
    {
        otp->rxDLL = 0;
        otp->txDLL = 0;
        otp->rdDelay = 0;
    }

    return status;
}

我们的想法是将对设置的搜索限制为仅使用 rdDelay 2，此外，我们将 rxDll 和 txDll 简化为一个小窗口，在该窗口中我们可以预期命中结果(这已经由现有算法完成)。 而不仅仅是该窗口内的测试点(大栅格)。 通过对成功 txdll 和 rxdll 设置的值进行加权、可以选择 txDLL/rxDll 与成功区域的中间位置耦合。

问题：
-扫描仅使用"rdDelay 2 (默认延迟2)"

专业版：
+对值进行加权避免选择奇异值(就像我们的 GigaDevice 一样)
+确定性运行时
+由于测试设置很少,运行速度更快

您对该算法有何看法？ 您是否发现任何问题？

尊敬的 Robert Czech：

Unknown 说：

您对此算法有何看法？ 您是否发现任何问题？

您打算多久调用一次该函数？

• 每次启动时？
• 定期执行低优先级任务？

此致、
Aakash

尊敬的 Aakash：

我们的想法是在每次启动时调用该算法。

您对温度变化的体验如何？只需确定一次理想设置就足够了吗？ 例如、在最坏的情况下 szenario 中、假设我们为 OSPI 设定200MHz 的时钟并且器件开始在-10°C 上引导、并且在应用程序中、器件随后加热至大约90°C 时、设置将消失多少 rxDL/txDll 步长？ 如果它仍处于有效区域、则无需重新调整设置。 否则、我们将需要一个任务来测量温度、并重试算法、以防我们超出温度范围、我们预计仍具有有效的设置。

此致、
罗伯特

尊敬的 Robert：

SDK 中的当前算法不包含用于选择最佳点的温度优化。 因此、您所描述的场景很可能会随着温度的升高而导致故障。 如果不进行测试或在寻找点时进行工作温度优化、就很难判断变化大小。 我将和一些软件专家进行探讨、并向您提供可能的解决方案、我主要是想评估优化该代码所花费的时间、以便将温度考虑在内、从而确定我们是否可以提出快速解决方案。 在我们的讨论之后、我将在星期一向您介绍最新情况。

此致！

丹尼尔  

尊敬的 Robert：

很抱歉在此主题上出现了延迟、我们在尝试联系合适的专家以帮助在代码中集成温度优化时遇到了问题。 我将在下周的讨论中再次提出这一问题、并在周三之前向您通报最新情况。  

谢谢。

丹尼尔

尊敬的 Robert：  

我将提交一个 TT、以在 AM243x SDK 的未来版本中包含温度优化。 我已经从处理器 SDK 中找到了这个实现、该实现在选择调优点时考虑了温度范围： nor_spi_phy_tune.c«ospi«norm«flash«src«board«ti«packages - processor-sdk/PDK - Unnamed repository；编辑此文件'escription'以命名存储库。

CGIT rep 中提供的代码适用于 AM64x、因此您可以将它用作 AM243x 的参考。 您将能够看到它是如何在1108-1110行中实现的：

请告诉我、这是否有助于您继续处理您的问题。

此致！

丹尼尔