尊敬的 Liang Lu：

我还将研究这个问题。 我需要 1-2 天的时间来回应。

此致、

Stan

您好、Stanislav、有任何更新吗？

尊敬的 Liang Lu：

我期望在一天或两天内拥有更好的示波器。 同时、从您的屏幕截图中、我只能猜测这可能是由于时间不正确而导致的短总线争用。

此致、

Stan

你好 Stanislav ,有消息吗?

尊敬的 Liang Lu：

很抱歉晚回复。 我不在办公室、我的团队成员在使用他的 PC 时遇到了问题。 我们会尽快回来。

谢谢、Stan

您好、Stan、另一周过去了。   预计何时更新。

您好 Liang Lu,

Stan 目前不在办公室。

到目前为止、我无法设法（使用新示波器）捕获   SK-AM64B 上 OSPI 读取场景的 OSPI_DQ4 半级（第一位）波形。

我将尝试联系另一个 TI 内部团队、该团队可以帮助我们进行更精确的测量。  

希望我们能在 2 或 3 天内收到新图片。

此致、

Anastas Yordanov

尊敬的 Anastas、Stan：

   任何新闻？

到目前为止、我无法（使用新示波器）捕获   SK-AM64B 上 OSPI 读取场景的 OSPI_DQ4 半级（第一位）波形。

您是否参考了上面的示例来修改用于验证的代码？ 为了触发这种现象、有必要确保接收到的第一个字节对应于位值 1。 此外、闪存芯片配置的虚拟时间应为 1 个周期短于 SOC 中设置的值、例如：

嗨、Liang Luo、

很抱歉、回复延迟。 我可以问您几个问题吗？

1.在原来的线程中,唐东尼说“也可以在 OSPI 引导过程中捕获它“。 这是正确的吗？ 在 OSPI 引导期间、我们没有看到半级问题。

2.从当前线程中捕获的波形:

与原始线程的波形不同：

这是现在的另一个问题、还是它是用另一个可能较慢的范围捕获的同一个半级问题？

谢谢、

Stan

尊敬的 Stan：

我们再次检查：  

负载 SBL 中无半电平、负载应用中无半电平。

因此、fsbl 似乎采取了有效的方法来避免这一问题。

2. 从当前线程捕获的波形：

嗨、Liang Luo、

谢谢你。 请期待我下周初的答复。

嗨、Stan、有什么新消息吗？

嗨、Liang Luo、

我对推迟我的答复表示歉意。

测量设置花费了比预期更多的时间。

我使用 TI SDK： mcu_plus_sdk_am64x_11_00_00_15。

SK-AM64B - S28H 中使用的闪存存储器 S 512T 与 AM243x EVM -   S28H 中使用的位不同 L 512T,但一般我没有注意到任何差异的关键参数你有重点在这个和上一个线程。

我在中进行了您的建议修改：

1) extern.syscfg — 在这种情况下，我禁用了 PHY 模式。

2) 我将 ospi_flash_dma.c（第 413 行）中的数据修改为 0xFFFFFFFFFFFFu

3) 在   ospi_flash_dma.c 的行 Ln123：“CycleCounterP_reset ()“中添加了断点

我总共设法捕获了 3 次 DMA 数据传输、因此通常看起来像：

我在下面的屏幕截图中捕捉了这种现象。 在第一个 DQ4 数据位持续时间内、线路在初始上升后保持其电平为 1.32V 并持续约 7 - 8ns、然后信号继续上升至 1.8V。

OSPI CLK 线路频率围绕 41MHz。 (~ 166.666MHz / 4)

我确认在运行时没有观察到第一个位半级效果 DEFAULT_SBL_null 引导加载程序。

此致、

Anastas Yordanov

我在下面的屏幕截图中捕捉了这一现象。 在第一个 DQ4 数据位持续时间内、线路在初始上升后保持其电平为 1.32V 并持续约 7 至 8ns、然后信号继续上升至高达 1.8V[/报价]

这就是我们所说的半级问题。

default_sbl_null 不访问闪存、并且当 fsbl 加载 SBL 时确实没有半级问题。 因此、我想您应该比较 fsbl 和 sbl/app 之间的闪存配置差异、看看这是否可以解决问题。

嗨、Liang Luo、

感谢您的澄清。 然后、我必须确实使用 OSPI SBL 执行测试。  令人惊讶的是、我可以成功刷写、但无法成功运行 SDK（提供的 OSPI_SBL 和示例应用程序）。 我已启动内部线程来解决此问题。

从 AM64x SDK 文档中：

AM64x SDK 文档 NULL SBL

我知道、尽管 NULL SBL 是从 OSPI 闪存（OSPI 引导模式）运行的、但它仅初始化内核和其他外设、但不会使内核加载并执行 OSPI 闪存的任何代码。  

在可以执行 fsbl/sbl/app 映像之间与闪存相关的 SysConfig 比较之前：我需要确保我们在以下理解下保持一致：

FSBL -

 1.我知道“FSBL"实际上“实际上是 AM243x/AM64x ROM 引导加载程序（即 SoC ROM 驻留代码）。 这是正确的吗？  

从您的陈述中：

default_sbl_null 不访问闪存、并且当 fsbl 加载 SBL 时确实没有半级问题。 因此、我想您可以比较 fsbl 和 sbl/app 之间的闪存配置差异、看看这是否可以解决问题。

2.到目前为止,我自己观察到 OSPI 半级读取问题在应用程序执行过程中表现出来。 （因为我尚未对 OSPI SBL 进行观察）。  我知道、当 FSBL 在执行之前将 ospi SBL 代码从 OSPI 闪存偏移 0x0 加载（传输）到片上 RAM 时、您没有观察到任何 OSPI 半级读取问题。 正确？

3. 您能否确认在 OSPI SBL 在执行应用程序之前将应用程序从 OSPI 闪存偏移量 0x80000 加载（传输）到片上 RAM 期间观察到 OSPI 半级读取问题？

谢谢

此致

Anastas Yordanov

1.是的、它在 TRM 中称为 RBL（主引导加载程序）。

 1.我知道“FSBL"实际上“实际上是 AM243x/AM64x ROM 引导加载程序（即 SoC ROM 驻留代码）。 这是正确的吗？  

从你的 statemen

2.是的。 没有半电平、频率= 25MHz。

我知道、当 FSBL 在执行之前将 ospi SBL 代码从 OSPI 闪存偏移量 0x0 加载（传输）到片上 RAM 时、您没有观察到任何 OSPI 半级读取问题。 正确？

当 SBL 从 OSPI 闪存加载应用时使用半电平模式。

您能否确认在 OSPI SBL 在执行应用程序之前将应用程序从 OSPI 闪存偏移量 0x80000 加载（传输）到片上 RAM 期间观察到 OSPI 半级读取问题？

Liang、

根据具有不同行为的波形、这看起来像是两个单独的问题。 但想了解更多信息进行确认。

由于信号发生骤降、而不是保持在接近 1/2 Vs 电平、因此捕获的波形似乎在发射上产生了反射。 我预计这是在远端测量的 AM243x 写入操作

您能否确认上述情况是否也是测量 读数据的第一位还是该操作捕获的是从 AM243x 器件发送/写入？

此行为不同、因为它在 1/2 Vs 阶跃保持恒定。 这对我来说是两种潜在的可能性之一。

1) 在闪存处的测量点正在捕获预期的反射。 在源端测量 LVCMOS 信号时、信号传输时将存在 1/2 Vs 阶跃、直到信号反射回并完全转换到 VDD。

2) 存在总线争用、其中 AM243x 器件和闪存器件都尝试驱动总线、从而导致 1/2 Vs。 我预计这只会发生在第一个读取周期、可以通过配置虚拟周期进行调整、如上一线程中所示。

很难判断、但似乎这种 1/2 Vs 处于读取时的每个上升沿

务必要了解、在闪存器件处测量是测量 AM243x 写入的正确点、但当闪存驱动信号时、这会导致读取失真。

如果可以在 AM243x 边界测量读取周期、那么这将是一个有用的数据点。 如果消除了 1/2 Vs 阶跃、则可以确认这是一个测量伪影。 如果继续、重点应放在虚拟周期配置和消除总线争用上。

谢谢、

Chris

您好、Chris、

修改虚拟周期可以消除这个半级、但将读取不正确的数据。  我们在上一个主题 https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1477203/am2434-ospi-read-command-first-bit-half-level-question/5739028?tisearch=e2e-sitesearch&keymatch=%20user%3A589657 中已经详细说明了这一点

我 也缺少足够的条件来测试来自 AM243X 近端的信号 如果是信号反射、则不应该在每次位从低电平转换为高电平时发生这种反射？ 此外、DQS 引脚上没有半电平。 所以 我认为信号反射的可能性相对较低。

如果可以在 AM243x 边界测量读取周期、它将是一个有用的数据点

Liang、

是、如果在闪存处测量粉色迹线并由闪存驱动 DQS、则我同意该迹线会显示相同的行为。 由于没有进行检测、并且基于上一线程中的讨论、因此它确实与虚拟周期和产生的总线争用有关。 我们需要让软件团队参与进来、因为这可能需要修改软件才能解决问题。

谢谢、

Chris

Chris、谢谢。

是否有预期的响应和解决时间表？ 此外、我们希望稍后了解该问题的根本原因。

尊敬的 Liang：

已分配此主题、如果需要调整软件、我将继续此主题。

请允许我花一天时间回复您、提供进一步的更新信息。

感谢您的耐心。

Vaibhav

尊敬的 Vaibhav： 如果有任何更新？

您好、

要获取有关此方面的更多更新软件配置信息（除了 Tony Tang 创建的早期主题）、请填写下表：

tbf ​

期待您的答复。

谢谢、

Vaibhav

这话什么意思？ 我是否需要再次填写表单？

我已经向您发送了重现问题的方法—您可以自己重现问题。 您甚至不能做最基本的总结？

两个月来、我们一直在不断讨论这个问题。 我们现在开始了吗？ 过去两个月的所有沟通是否只是浪费了精力？

效率是否始终如此低？ 每一次,只有当我推动的时候,才会有一些进展。

您好、

上表将用作软件摘要。

请告诉我您正在引导的引导模式？ 是 xSPI/OSPI/QSPI 引导模式、请参阅 TRM 中的第 5.4.1 节、详细了解引导模式引脚配置 B3 - B9

我看到您编写了 25MHz、但没有提到引导模式。 我是这样问的、以便我可以继续比较以下情况：

因此、请比较 fsbl 和 sbl/app 之间的闪存配置差异、看看这是否能解决问题。

期待您的答复。

谢谢、

Vaibhav

我已经向您发送了重现问题的方法—您可以自己复制问题。 您甚至无法进行最基本的总结？

根据上述响应重复了该问题、因此我们需要使用引导模式配置来比较寄存器的差异。

注意、根据复制情况、出现了如下所述的问题：

我在下面的屏幕截图中捕捉了这一现象。 在第一个 DQ4 数据位持续时间内、线路在初始上升后保持其电平为 1.32V 并持续大约 7 - 8ns、然后信号继续上升至 1.8V。[/报价]

此外,从早期的线程: https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1477203/am2434-ospi-read-command-first-bit-half-level-question/5739028?tisearch=e2e-sitesearch&keymatch=%20user%3A589657

我们掌握了有关频率的信息、但 在表格中填写其他因素会有所帮助。

在 EVM 电路板上、我们遵循 EVM_SETUP_PAGE 文档指南以使用 OSPI 引导模式（实际上应该是 xSPI）、并采用其他配置、包括 OSPI 频率完全设置为默认值。

在我们自己的电路板上、我们使用了 xSPI 和 SPI 引导模式。

您好、

在我们自己的主板上、我们使用了 xSPI 和 SPI 引导模式。

假设 xSPI 和 SPI 引导模式都不会对显示半电平问题的波形产生问题、我将比较 RBL 和应用程序的 OSPI 配置寄存器。

请稍后回复。 感谢您的耐心。

谢谢、

Vaibhav

尊敬的 Liang：

我承认其他高优先级问题造成的延迟。

如果我对此有一些发现、请期待得到回复。

此致、

Vaibhav

i2189？ 实际上、无论是否使用 phy 模式、都需要一个额外的虚拟周期

以下是 OSPI 的寄存器值。

就在 ROM 启动后、这些值如下所示：

在 Board_drivers 之后启用了 PHY 和 DMA 的 OSPI 闪存 IO 应用打开：

请允许我在某个时候 看到它们之间的区别。

你好、Vaibhav、

是否有更新？

您好、

感谢您的耐心。

我已经回顾了这些差异。

其中一些重要的因素是：  

ROM：

虚拟周期：20

DELAY_FLD 位值= 1

OSPI 闪存 IO：

虚拟周期= 25

DELAY_FLD 位值= 1

您可以尝试提交并构建示例吗？ 请查看 commit：https://github.com/TexasInstruments/mcupsdk-core-k3/commit/490656d87db71516007f6b23fadca60ab3feffb2 中的更改是否仍然出现半级问题

期待您的答复。

谢谢、

Vaibhav

您是否验证过它？  我尝试了,但它不起作用。

您可以尝试提交并构建示例吗？ 请查看 commit：https://github.com/TexasInstruments/mcupsdk-core-k3/commit/490656d87db71516007f6b23fadca60ab3feffb2 中的更改是否仍然出现半级问题

期待您的答复。

由于 TI 在 EVM 上复制了该问题、我建议 TI 在让客户尝试之前进行证明。 该问题已解决很长时间。

尊敬的 Tony、Liang：

我已经开始与硬件和软件团队进行内部讨论、以便快速跟踪此问题。

随着我们的进步、我将与您分享最新信息。

此致、

Vaibhav

尊敬的 Liang：

根据我与 SW 团队的调试结果得出的一些观察结果。

当在 SysConfig GUI 中未选中（启用）PHY 模式时：

控制器侧虚拟时钟（读取）应等于闪存侧虚拟时钟（读取）。

当在 SysConfig GUI 中选中（启用）PHY 模式时：

控制器侧虚拟时钟（读取）应比闪存侧虚拟时钟（读取）大 1。

如果时钟频率/分频器的值<= 25MHz、则虚拟时钟 (CMD)= 3

如果时钟频率/分频器的值大于 25MHz 且<= 50MHz、则虚拟时钟 (CMD)= 4

此致、

Vaibhav

嗨 Liang、Tony、

您能否帮助根据以下几点对上述波形进行分类？

OSPI 接口上会发生两个问题：

• 总线争用–同时驱动总线的闪存和 SOC 将导致持续的中电平信号。 可能仅第一次转接。
• 反射–电压实际上会降至以下、并显示一些振铃迹象。 与布局/布线长度/电路板设计有关。 有助于更改布局并可能提高驱动强度。 发生从低到高的事务时将发生。

期待您的答复。

谢谢、

Vaibhav

尊敬的 Vaibhav：

当在 SysConfig GUI 中未选中（启用）PHY 模式时：

控制器侧虚拟时钟（读取）应等于闪存侧虚拟时钟（读取）。

您如何对此进行测试？ 如果相等、 则将读取不正确的数据。

当在 SysConfig GUI 中选中（启用）PHY 模式时：

控制器侧虚拟时钟（读取）应比闪存侧虚拟时钟（读取）大 1。

如果时钟频率/分频器的值<= 25MHz、则虚拟时钟 (CMD)= 3

如果时钟频率/分频器的值大于 25MHz 且<= 50MHz、则虚拟时钟 (CMD)= 4

为什么？ 启动该主题的目的是了解此类配置背后的原因以及如何解决半级问题。

嗨 Liang、Tony、

梁罗说：

您能否帮助根据以下几点对上述波形进行分类？

请参阅上一份答复、如下所示。

您好、Chris、

修改虚拟周期可以消除这个半级、但将读取不正确的数据。  我们在上一个主题 https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1477203/am2434-ospi-read-command-first-bit-half-level-question/5739028?tisearch=e2e-sitesearch&keymatch=%20user%3A589657 中已经详细说明了这一点

我 也缺少足够的条件来测试来自 AM243X 近端的信号 如果是信号反射、则不应该在每次位从低电平转换为高电平时发生这种反射？ 此外、DQS 引脚上没有半电平。 所以 我认为信号反射的可能性相对较低

OSPI 接口上会发生两个问题：

• 总线争用–同时驱动总线的闪存和 SOC 将导致持续的中电平信号。 可能仅第一次转接。
• 反射–电压实际上会降至以下、并显示一些振铃迹象。 与布局/布线长度/电路板设计有关。 有助于更改布局并可能提高驱动强度。 发生从低到高的事务时将发生。

期待您的答复。

您希望客户和我做出什么样的回应？  

我们报告了问题、需要 BU 团队分析、您是否将球踢回我们进行分析？

如果需要我的选项、我认为这是总线争用、因为修改虚拟周期号可以消除第一个位中间级异常信号、但结果是错误的。 所以我认为它可能与 IP 相关、建议您与 IP 供应商合作进行分析。  

它并不一定会反射、因为修改虚拟周期会消除中间电平信号。

由于 BU 团队已经在 EVM 上重现了该问题、因此 BU 可以验证有关 EVM 的想法并向客户提供结论。

您好、

执行 Liang 提到的步骤。

我已在 AM243 EVM 上刷写了 default_sbl_null.cfg 文件。 然后、在通过 CCS 加载 OSPI 闪存 DMA 并在第 123 行（禁用 PHY）放置断点时、我看到 DQ4 的第一位如上图所示。

我看不到 Anastas 和 Liang 看到的半级问题。 我的下一步是查看 Anastas 如何与我的设置不同运行。

谢谢、

Vaibhav

尊敬的 Vaibhav：

我认为您的波形也会重现此问题；否则第一个时钟的电压电平不会大幅下降。 示波器的性能可能较差或未与产品接地、这可能是波形不是很清楚的原因。

此外、

1.如何测试? 我尝试并 收到错误的数据

当在 SysConfig GUI 中未选中（启用）PHY 模式时：

控制器侧虚拟时钟（读取）应等于闪存侧虚拟时钟（读取）。

2.你是否证实这不是原因?

我确认由于其他高优先级问题而导致的延迟。

尊敬的 Liang：

我进行了一些实验。 我看不到任何总线争用、以及擦除、写入和读取操作也正确进行。

在控制器上读取设置 24、闪存侧读取设置 24 的情况下、我能够读取这些值。

我已经调试它并发现以下观察结果：（在用于 OSPI 闪存 DMA 的 SysConfig 中、将控制器和闪存读取周期设置为 24）

1. 在 Flash_norOspiOpen 函数中、我们首先在读取器件和制造 ID 时设置 readDataCapDelay 值 （客户无需对此步骤执行任何操作，只需解释流程即可。）
2. 发布此步骤、在应用程序中、要求客户在以下行放置一个断点：
   
3. 这将确保 DAC 处于启用状态。 在“Memory Browser“中转到地址 0x60000000。 在这里,您将看到引导加载程序映像刷新,它应该以类似 3082 的内容开始。 . . 以此类推。
4. 您会发现引导加载程序映像会随着中间的一堆“00 00“而变化。 在我的设置中看到这一点。
   （由于一些干扰，我截取屏幕截图时图像发生翻转）
5. 我发现这可能是一个 readDataCaptureDelay 问题。
6. 因此、我将寄存器 0xFC40010 位[1：4]的值更改为 5、这对我来说很有用。 之前的位[1：4]配置为 1、现在我写入的更新值为 5、因此现在将位[1：4]配置为值 5、我可以看到正确的内容、如下图所示：
   
7. 我希望您使用从 15 到 0 的值进行测试、并告诉我哪个值可以在 0x60000000 处为它们提供正确的内容。

后续步骤：

如果在客户设置时复制了该文件、则可以建议后续步骤。

期待您的答复。

谢谢、

Vaibhav

尊敬的 Vaibhav：  

我在 EVM 板上进行了测试、位[1：4]= 4 或 5 可以、其他值不正常。

接下来星期一、我将测试我们自己的电路板以查看效果是否一致

尊敬的 Liang：

我将在星期一上等待您的结果。

请提供上述步骤中所述的 24 个和 24 个虚拟周期、并且对于您自己的（定制）板也请执行相同的操作。

如果不是 5、则也尝试从 15 到 0 的其他值。

我很期待这件事。

谢谢、

Vaibhav

嗨、Vaibhav、在我们的电路板上 (S28HL256T/S28HL512T)、5 和 6 可以、其他值为 NOK。

尊敬的 Liang：

该专家目前不在办公室、将再次使用星期四。 对此主题的响应将延迟。 如果您 在本周结束时未收到回复、请 ping 通该主题。

此致、

Tushar

尊敬的  Vaibhav：

  是否有最终解决方案、特别是如何修改代码？ 是否计划更新 SDK 和勘误表来优化该问题？