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.
您好、TI 专家!
客户正在处理 TDA4VH SDK9.0客户板 ,引导模式为 SPL 。
它们具有 使用 SD 卡启动时没有问题 那样。
最近、由于他们的项目即将实现大规模生产、他们需要 更改以使用 eMMC 引导 ,并且发现了以下问题。
首先、他们使用的是 西部数码(自有 SanDisk 公司) SDINBDG4-16G-XI1 ,相应的数据表如下所示。
e2e.ti.com/.../SDINBDG4_2D00_Industrial.pdf
问题是、它需要一个 eMMC 引导失败的可能性很大 ,只有一个 使 eMMC 能够成功启动 。 (室温下)
当 eMMC 引导失败时、它将具有 以下3个不同的错误日志 。
错误日志1:
错误日志2:
错误日志3:
如果 eMMC 成功引导,它将具有以下成功引导日志(HS400):
我们已完成硬件和软件调试测试、我已在下面进行了总结、请查看结果、谢谢!
测试1
我们已尝试将下面的 regmap_RED_POLL_TIMEOUT 参数从20增加到2000、结果表明 eMMC 引导成功的可能性提高了一点、但仍然有机会发生上述引导失败。
测试2
我们已经检查了 时钟和 D0以及 DS 的波形、其 在下面看起来很正常。
测试3
我们已测试了 eMMC 延迟、 下面的测试数据看起来是正常的。
测试4
我们已在高速模式(50MHz)下进行了测试、根据 JESD84-B51标准的要求、CMD 信号的保持时间似乎不够。 此外、在高速模式下、只有在 eMMC 引导成功时才能捕获波形、并且只能在内核引导阶段捕获波形。 请查看以下内容。
从上面的测试数据中可以看到、输入 CMD 保持时间为1.706ns。
但是、根据下面显示的标准的要求、保持时间的最小值应为3ns。
该结果是否与我们的 eMMC 启动问题有关?
我们怀疑这意味着时间差是不够的,但我们不是很确定。
测试5
根据测试4结果、我们已尝试以下实验。 在下面的 MMC0_CMD 行(图片显示了默认的硬件原理图、没有任何更改)中、我们已尝试将 R3808从0Ω 更改为10Ω,、并并联添加了一个非常小的电容器 C4918 (4.7pF)。
结果表明、在更改硬件后、我们每次都可以在 HS400模式下成功引导 eMMC。
但是、以下原因导致我们无法采用该解决方案来解决此问题。
我们已在如下所示的默认硬件设置中仔细检查了时钟和 CMD 的时间系列、 它实际上已经满足 eMMC 标准中的总线时序
进行上述硬件更改后、时钟和 CMD 的时间系列不如以前那样好、如下所示。
我们可以看到、尽管我们可以通过此方法成功引导 eMMC、但波形变得很差(不像预期的方波)。
另外、我们已经在添加电阻器和电容器后检查了 CMD 保持时间、可以看到保持时间更接近所需的最低要求3ns (从1.7ns 更改为2.0ns)。 如果添加了更大的电容、则保持时间将达到标准要求3ns、但增加的电容越大 、波形越差、它完全不像方波、因此我们无法采用该解决方案。
对于我们的设计、另一个重要信息是、我们有两代电路板。 在第一代中、PCB 布线长度为 1770密耳 。 在第二代器件中、PCB 布线长度优化为 1370mil 。 对于相同的软件设置、它可以在第一代电路板上以 HS400模式成功引导 eMMC、但对于第二代电路板、会出现上述问题。 我们已测试 TDA4VH EVM 的 PCB 布线长度 2000密耳 。 我们能否怀疑默认 EVM 设计的时序裕度不够充分、因此如果我们优化 PCB 布线长度、可能会有这个问题?
我们可能需要根据我们的实验结果获得一些建议,谢谢!
我们还发现、一些类似的帖子最近具有如下所示的相同错误日志。
我们希望获得基于这些信息的进一步调试建议、感谢您的帮助!
此致、
凯文
您好、TI 专家!
客户也尝试执行以下测试。
第1步:将 Uboot 级中的 eMMC 速度从 HS400降至 HS200
第2步:保持内核引导阶段的 eMMC 速度与 HS400相同、这意味着在电路板启动后、系统中读取的最终 eMMC 速度仍为 HS400。
第二代具有 1370mil PCB 布线长度现在也可以成功引导 eMMC。
默认 SW 设置的唯一变化是仅在 uboot 级中降低 eMMC 速度。
下面我简单总结一下。
对于 PCB 布线长度为1770mil、迹线长度为±10mil 并且保持时间为2.1ns 的第一代电路板、uboot 和内核引导阶段都支持 HS400。
对于具有1370mil PCB 布线长度、 ±30mil 布线长度失配和1.7ns 保持时间的第二代电路板、仅内核引导阶段支持 HS400、但在 uboot 阶段、我们必须降至 HS200才能引导。
基于上述发现、我们还根据下面所示的 JESD84-B51标准检查了2项更多信息。
1:HS400和 HS200的 CMD 输入时序要求相同、最小为3ns。 尽管在两个2代电路板中、测得的保持时间都小于最短保持时间、但如果要求相同、我们不知道为什么 uboot 引导级中的 HS200可以工作、但 HS400无法用于第二代电路板。 此参数是否重要?它与 uboot eMMC 速度之间的关系如何?
2:走线长度不匹配的最小值应达到 ±1mm、相当于 ±40mil。 尽管在我们的第二代电路板中、测量出的 布线长度失配是 ±30mil、大于我们第一代电路板的 ±20mil、但仍然满足±40mil 的要求。 因此,我们认为这不会导致问题。
请帮助分析这些信息和我们目前取得的实验结果。
我们期待着在此基础上获得一些建议和进一步的调试想法。
此外、是否有任何有助于调试此问题的工具?
非常感谢!
凯文
尊敬的 Kevin:
首先、他们使用的是 西部数码(自有 SanDisk 公司) SDINBDG4-16G-XI1 ,相应的数据表如下所示。
问题是、它需要一个 eMMC 引导失败的可能性很大 ,只有一个 使 eMMC 能够成功启动 。 (室温下)
当 eMMC 引导失败时、它将具有 以下3个不同的错误日志 。
[/报价]遗憾的是、eMMC 与我们在电路板上使用的测试不同、因此我们可以重现准确测试。 eMMC 引导故障率很高、这可能会成为 eMMC 器件问题、但在我们得出这一结论之前、我需要先测试并尝试一些方法。
- 这是否仅在 eMMC 引导模式下发生? 其他引导模式是否可以像 OSPI 一样工作?
- 对于3个不同的错误日志:
- 最常发生的是哪种情况?
- 它们是随机发生的还是类似的次数?
- 您是否曾尝试过较早版本的 SDK 并进行测试、以查看是否出现关于保持时间和 eMMC 引导失败的相同错误?
对于基于 PCB 布线长度的保持时间差异、我无法对此进行评论、但我已在内部进行了沟通以找到更多相关答案。
此致、
马特
您好、Matt、
感谢您的答复。
是的、此问题仅在 eMMC 模式下发生、仅在客户的第二代电路板上发生。
此问题与 SDK 版本无关、但与保持时间和 PCB 布线长度不匹配有关。
第二代电路板上的不同 SDK 版本具有相同的结果。
第一代电路板上的相同 SDK 版本可能通过、但第二代电路板上的相同 SDK 版本将失效。
对于错误日志、它们似乎是随机发生的。
前面总结、第一代电路板具有2.1ns 的保持时间和10mil 的 PCB 布线长度失配、第二代电路板具有1.7ns 的保持时间和30mil 的 PCB 布线长度失配。
我们还测试了 TDA4VH EVM 板、测量了 EVM 板的保持时间、也不符合 需要3ns 的 JESD84-B51标准。 结果约为1.9ns、如下所示。
那么根据这个结果、我们是否可以认为保持时间不是必需的要求?
如果是、那么第一代电路板与 EVM 电路板和第一代电路板之间的唯一区别是 PCB 布线长度不匹配。
我知道30mil 的失配是否可以接受、因为从我们的数据表中可以看到小于1mm (40mil)的情况。
此致、
凯文
您好、TI 专家!
正在更新当前状态。
如果我们在第一代电路板中使用 HS400模式(第二代电路板具有上述 eMMC 错误)而不出现 eMMC 错误、则速度仍与 HS200类似。 但是、从 eMMC 数据表中、它声称应该支持 HS400。
下面提供了我们的实验测试结果。
我们使用的命令为:
#cat 003-fio-test.sh
#!/bin/sh
RM -RF fiotest_read fiotest_write
echo "\n\n=========================== FiO 读取测试=========================================== "
fio -fileName=fiotest_read -direct=1 -iodepth 1 -thread -rw=read -IOEngine=psync -bs=16k -size=1G -numjobs=2 -runtime=100 -group_reporting -name=mytest
echo "\n\n=========================== FiO 写入测试=========================================== "
fio -fileName=fiotest_write -direct=1 -iodepth -rw=randwrite -IOEngine=psync -bs=16k -size=1G -numjobs=2 -runtime=100 -group_reporting -name=mytest
得到的结果为(读取和写入1G 文件):
HS400读取:137Mb/s
HS400写入:75.7Mb/s
HS200读取:132Mb/s
HS200写入:70.5MB/s
此致、
凯文
Kevin 老师好!
如果我们在第一代电路板(第二代电路板具有上述 eMMC 错误)中使用 HS400模式而没有 eMMC 错误、则速度仍类似于 HS200。 但是、从 eMMC 数据表中、它声称应该支持 HS400。
在 HS400的读写测试期间、您是否在 Linux 中获得了任何错误/恢复?
此致
迪瓦卡尔
尊敬的 Diwakar:
感谢您的回复!
在客户的第一代电路板中、eMMC 引导没有任何错误或恢复、而且当我们进行 eMMC HS400性能测试时、Linux 上也没有显示错误或恢复。
请参阅以下日志、了解 eMMC 读写性能测试、谢谢!
在 HS400上读取 eMMC:
HS400上的 eMMC 写入:
对于第二代电路板、由于 PCB 布线长度不匹配从10mil 增加到30mil、因此会出现上述误差并卡在 Uboot 级。
我们还怀疑这与保持时间有关。 在 JESD84-B51标准中、最小保持时间要求为3ns。 这也是唯一不符合我们实验结果中所示要求的数据。 对于客户的第一代电路板、测得的保持时间为2.1ns、对于第二代电路板、测得的保持时间为1.7ns。 他们测得的 EVM 保持时间约为1.9ns (这可能需要我们的硬件专家进行复查和验证)。
此致、
凯文
尊敬的 Kevin:
我们也怀疑这与保持时间有关。 在 JESD84-B51标准中、最小保持时间要求为3ns。 这也是唯一不符合我们实验结果中所示要求的数据。 对于客户的第一代电路板、测得的保持时间为2.1ns、对于第二代电路板、测得的保持时间为1.7ns。 他们测量的 EVM 保持时间约为1.9ns (这可能需要我们的硬件专家仔细检查和验证)。
实际上、我们不会为使用调优的速度模式规定保持/设置时间。 请参阅数据表、了解传输开关要求。
此致、
马特