[参考译文] 编译器/TMDSLCDK6748：RTS 库导致 EMIF 问题？

非常感谢！

Yordan、您好！

只是想确认我们仍然看到这个问题。 设计团队是否能够查看？ 同样、我很乐意根据需要提供更多信息和背景信息。

此致、

David

您好、Rahul、

非常感谢您在此问题上提供的帮助。 自从我上一个帖子以来、我已经取得了一些进展、但我将在回答您的问题后再进行讨论。

您是否检查了 EMIFA 配置寄存器？ 有什么区别吗？

我已经比较了 EMIFA 配置寄存器并确保它们是相同的。

您使用的驱动程序是否与 NAND 写入器使用的驱动程序相同？ 请查看函数 NAND_OPEN 和 LOCAL_flashGetDetails、了解 NAND 写入器如何从 ID 字节读取 ONFI 字符串。

在尝试调试此问题时、我熟悉了 NAND 写入器驱动程序及其功能、包括您提到的功能。 我使用的代码几乎与驱动程序完全相同、但在不完全相同的情况下、它在功能上是相同的。

我偶然发现了一种通过调整构建的链接顺序来"解决"问题的方法、但这种解决方法会导致另一个问题。 让我解释一下：

当我在(我假设) XDC 为 SYS/BIOS 生成的"生成的链接器命令文件"之前链接"lrts64plus_elf.lib"时、我确实会得到预期的"ONFI"响应从 NAND 高速缓存寄存器中移出。 成功！ ...我想过了。

遗憾的是、此更改似乎也会禁用 TI-RTOS。 任务无法运行，系统似乎空闲，不执行任何操作--卡在 SYS/BIOS 函数 Task_allBlockedFunction()中。 为了清晰起见、我附上了几个屏幕截图。

从链接顺序列表中删除所有条目后、行为与"OOOOO"案例(第二个屏幕截图)相同。

由于我不熟悉 XDC 和 TI_RTOS 的内部工作原理、我必须承认、我对这里发生的情况一无所知。 如果您能提供任何想法或见解、我们将不胜感激。

谢谢、

David

Rahul、

我从平台中排除了多个段、并使用我自己的链接器命令来定义这些段。 到目前为止、这真的不是一个问题。

我已附上项目的精简版本以及可能需要的几个额外资源。 在当前配置中、如果在 nandwriter.c 的第171行上放置断点、则会在 devID16[]中看到正确的"ONFI"响应、但时钟模块和信标将不会执行。 尝试切换-lrts64plus_elf.lib 的链接顺序和生成的链接器命令文件、您会发现时钟和信号量正常工作、但 DSP 读取"OOOO"以获取 ONFI 响应。 (删除所有链路顺序规范会导致相同的行为。)

请告诉我、我是否可以提供任何澄清、或者您是否需要任何 其他包含文件。 感谢您对此提供的帮助。

非常感谢、

David Askew

e2e.ti.com/.../1050.PDI_5F00_Core_5F00_NAND_5F00_Example.zipe2e.ti.com/.../1526.PDI_5F00_Additional_5F00_Resources.zip

附件是我正在使用的自定义平台。

戴维

e2e.ti.com/.../1588.Platform_5F00_evm6748custom.zip

如果您向我提供了所需文件列表和包含路径、我会很乐意将其上传到此处。

除了您可能缺少的一些其他文件之外，我还附加了自定义文件“tistdtypes2.h”，它本质上是标准的“tistdtypes.h”，其中删除了某些 typedef。 这是将 NANDWriter 驱动程序导入到 TI-RTOS 项目的结果。 我删除了这些特定的 typedef、因为它们会导致有关"类型名称的无效重新声明"的错误。 例如、"int8" typedef 在 tistdtypes.h 中定义为"char"、但也在\ti\xdctools_3_30_06_67_core\packages\XDC\std.h 中定义为"XDC_Int8"

这让我更概括地说、我怀疑整个问题是将 NANDWriter 驱动程序导入到 TI-RTOS 项目中的结果。 (NANDWriter_DSP 项目未在 TI-RTOS 项目中创建)。 导入不是一个简单的过程、因为它需要修改一些文件(例如 tiddtypes2.h)、以避免导致编译器和链接器错误的兼容性问题。

"另请n`t、RTOS 在链接器命令文件中包含所需的 RTS 库、因此您无需显式链接到 rts64xplus_elf.lib"

是的、自动生成的链接器命令文件包括"ti.targets.rts6000.ae674"库、但不包括 rts64xplus_elf.lib。 正如我在上一篇文章中提到的：当删除到 rts64xplus_elf.lib 的显式链接时、读取 ID 命令的响应变为"OOOOOO"而不是"ONFI"、因此我一直被原始问题困扰。

据您所知、是否有人在 TI-RTOS 项目中成功实施了 NANDWriter 驱动程序？ 演示此任务的基本示例项目可能就是我解决问题所需的全部内容。 TI-RTOS 项目是否应该使用其他一些 NAND 芯片驱动程序？ 我们一如既往地非常感谢您的建议和帮助。

谢谢、

David Askew

e2e.ti.com/.../8831.PDI_5F00_Additional_5F00_Files_5F00_tistdypes2.zip

您好 Rahul、您是否有机会了解这一点？

我尝试单步执行来找出是什么导致 SYS/BIOS 在 Task_allBrokedFunction()中挂起。 无限循环出现在 Task.c 中的第255行：

void Task_startCore (UINT CoreID)
｛
// 
/*在任务就绪前停止*/
while (Task_module->curSet = 0)｛
Task_allBrokedFunction()；
}

// 

｝ 

我应该重申、只有在"生成的链接器命令文件"之前明确链接 rts64xplus_elf.lib 时、才会出现此问题。 但是、如果我没有明确添加 rts64xplus_elf.lib (并首先链接它)、那么从 NAND 高速缓存寄存器的读取操作将无法正确移出、正如我所描述的那样。

我的问题确实归结为：

如果这两种情况下的反汇编是相同的、并且 EMIFA 控制寄存器在这两种情况下也是完全相同的、那么 RTS 库及其链路顺序如何改变 NAND 芯片的行为？

这是我看到的现象。 TI-RTOS 链接的 RTS 库在某种程度上会导致 NAND 器件和 DSP 之间的接口出现功能障碍。 是否有人在 TI-RTOS 项目中成功实施了 NANDWriter 驱动程序？

谢谢、

David Askew

RandyP、

非常感谢您的周到建议。 我在上一个帖子中不清楚的一点是、我遇到了这个问题、即使是从同一个项目中执行完全相同的反汇编、但链接顺序不同。 因此、我们也许可以将#2从名单中删除。 (原始帖子是由两个不同但相似的项目汇编的–其中一个项目定义了非常大的栈大小。 这是在我意识到链路顺序是决定因素之前。)

至于#1、我希望这可能会导致问题的根源。 比较两个版本的.map 文件、即具有不同链接顺序的同一项目、很明显有很多不同。 尽管我仍在研究、但我认为最好提供此状态更新。 我还附加了两个.map 文件供参考(重命名为.txt 文件以便上传)

我想知道高速缓存/非高速缓存是什么导致了写入和读取 NAND 存储器时的问题。 但是、我不确定测试这种情况的最佳方法是什么。

再次感谢您的帮助和见解。 现在肯定有一些线索要跟踪！

此致、
David Askew

e2e.ti.com/.../NAND_5F00_Broken_5F005F00_RTOS_5F00_Working.txt  e2e.ti.com/.../NAND_5F00_Working_5F005F00_RTOS_5F00_Dead.txt 

RandyP、

我在这两个版本中单步执行该循环、并记录了相关寄存器的值。 我发现唯一真正的区别是从 NAND 高速缓存寄存器中读取的值。 我附加了一个 Excel 工作表、其中显示了记录的值。

在工作版本中、您可以看到在读取操作后 NAND 高速缓存寄存器(0x62000000)在哪里移出接下来的16位数据。 在不工作的版本中、移位永远不会发生；存储器浏览器可以在0x62000000处看到"O"、在0x62000002处看到"N"等、但由于寄存器不会移位、NANDWriter 驱动程序只读取字符串"O"而不是"ONFI"。

奇怪的是、EMIF 配置寄存器在这两种情况下看起来是相同的。 明天我将需要对此进行更多思考。

谢谢、
David

e2e.ti.com/.../PDI_5F00_Assembly_5F00_Stepthrough_5F00_Regs.xlsx

我仔细检查并比较了两个编译的.map 文件、发现数据和/或程序存储器位置没有明显差异。 它们 只是在模块数量上有所不同。 (版本中的模块具有可正常工作的 NAND、但损坏的 SYS/BIOS 看起来几乎像其他版本的子集)。

除此之外、唯一显著的差异是.stack 段的开头。 在 NAND 数据无法移位的版本中，.stack 的开头被分配给 boot.ae674：boot.oe674 (.stack)，而在 SYS/BIOS 无法调用任务的版本中，.stack 的开头被分配给 rts64plus_elf.lib：boot.obj (.stack)。

单步执行 NAND 数据被读取的循环、除了 EMIF (地址0x62000000)从 NAND 芯片的高速缓存寄存器中读取的数据之外、我在汇编甚至寄存器值方面没有发现任何差异。 我之前的帖子包括这方面的记录。 我已经进行了三次检查、两种情况下所有 EMIF 寄存器都是相同的。 实际上、SYS/BIOS 库会使 EMIF 无法正确连接、但我不确定如果 EMIF 寄存器都相同、这是怎么可能的。

侧注：

在过去的两个月中、我曾多次但恭敬地向 Rahul Prabhu 提出任何问题、以指导或深入了解 SYS/BIOS 中断 EMIF 异步控制器的问题。 很少得到答复。 我还试图通过私人信息向 Rahul 发出信息，但在我键入此帖子时，这一信息仍未得到答复。

我没有足够的资格(或足够的能力)声称在 SYS/BIOS 中发现了缺陷。 我很可能错过了一些东西；不幸的是，我很少有理由这么想...至少直到上周。 我认为，拉胡尔在这一问题上的坚定沉默只能用几种方式来解释：要么是出于不礼貌和疏忽的结合，要么是表示 SYS/BIOS 确实存在问题的迹象。

RandyP 非常感谢您慷慨地前往另一个领域并提供帮助、这真的很有帮助。 如果你或拉胡尔最近的帖子有任何需要补充的内容，我一定会欢迎它的。 感谢你能抽出时间。

此致、
David Askew

RandyP、

我知道其中一些不是您的主要领域、我非常感谢您的帮助。

NAND EMIF NANDFSR 中是否出现任何错误？

否、在任何情况下都不是。 在这两种情况下、所有 EMIF 寄存器看起来都相同。

两个.stack 段放置在什么物理地址中、它们的大小是多少？

在这两个构建中、堆栈部分位于 L2 RAM 的开头、TMS320C6748上的 RAM 为0x11800000。 它与 L2 RAM 大小相同：两种情况下均为256KB。 对于 SYS/BIOS 和一些 NAND 驱动程序几乎为空保存的项目、我认为这就足够了、但我会尝试稍微调整一下大小、看看会发生什么情况。

请发送指向 BIOS 中断 EMIF 线程的链接。

我实际上是指这个线程。 您将注意到它是两个月前开始的。 在此期间、我发现是由 RTS 库引起 NAND 问题。 (明确地先链接另一个库 rts64plus_elf.lib、实际上可以修复 NAND 问题、但会导致 SYS/BIOS 操作出现问题。)

由于 DSP 汇编代码和寄存器数据在这两种情况下基本相同、我假设 SYS/BIOS 在与 NAND 存储器连接时处理 EMIF 的方式一定有问题。

Rahul 是最优秀的之一、这也意味着我们卓越的 E2E DSP 支持团队中最繁忙的一个。 他很清楚这一问题。

考虑到他的工作所在公司、我毫无疑问 Rahul 既称职又博学。 毫无疑问、他也很忙、但很难证明这个问题被忽略了。 每周都有答复，但 Rahul 在其他地方继续积极参与这些论坛。 我真的很想在这方面出错。 正如您所说的、我确实希望他知道 SYS/BIOS-EMIF 问题、尽管有一些指示会更好！

无论如何、再次感谢您的持续关注。 我将研究堆栈大小的想法。

此致、
David Askew

David、

对于此问题的延迟答复、我深表歉意。 我参与了针对 Processor SDK RTOS 的发布阻止问题的调试、这就是为什么我无法回复 e2e 帖子、这些帖子需要更多的参与、而不是将用户指向正确的资源来解除对其开发的阻止。

如前所述、由于您之前共享的 zip 文件中有几个文件缺失、我无法重现此问题。 此外、我能够将 NANDWriter 代码添加到任务并使用 TI RTOS 和 SYSBIOS 运行它、而不会出现任何问题、但根据您之前的分析、您似乎也没有遇到此问题。  

目前、最好的方法是为我提供一个包含所有必需文件和文档的自包含项目、以帮助在 LCDK 上重现此问题。 从目前的分析来看、不清楚问题是由 TI RTOS 配置/编译器造成的、还是由您项目中的某些集成问题引起的、以便我为您提供具体的指导。  

除了 Randy 提供的指导之外、查看映射文件 DSP 缓存配置也很有用。 TI RTOS 为此平台启用缓存、并使用 BIOS 内核中的平台设置、而不是链接器命令文件。 另一个要尝试的操作是将编译器降级到 CGT 7.4.16、看看这是否会产生影响。 如您所见、闪存实用程序中的 NANDWriter 是随 CCS 工程和旧编译器一起提供的、因此我不确定这是否会有所不同。

此致、

Rahul

PS：我还要求 C6000编译器专家查看链接顺序、并就这在这种情况下产生影响的原因提供评论。

Rahul、

感谢你的答复。

[引用用户="Rahul Prabhu"]

由于您之前共享的 zip 文件中缺少几个文件、我无法重现此问题。 [...]继续前进的最佳方式是，如果您可以为我提供一个包含所有必需文件的自包含项目[...]。

[/报价]您会注意到、在后续帖子中、我提供了我认为是构建项目所需的附加文件。 但是、为了方便起见、我会将所有内容组合成一个 zip 文件并重新上传。 (请参阅下面的)

关于"自包含工程"：我没有包含工程所需的每个单源文件、头文件和库、因为这样的工程当然会非常大–我假设您已经有标准软件包、如 MCSDK、CSL、XDCtools 和 TI-RTOS。 但是、我相信所需的所有其他附加文件都包含在 zip 文件中。 为了便于移植、我尽可能在项目中使用路径变量。 如果您丢失了任何其他文件、请告诉我；我保证我会及时将这些文件发送给您。

在当前配置中、您将注意到 rts64plus_elf.lib 最后被链接、从而导致对读取 ID 操作的"OOOO"响应。 请注意、当 rts64plus_elf.lib 完全从工程中删除时、此行为是相同的。 相反、如果您首先链接 rts64plus_elf.lib、则会观察到适当的"ONFI"响应、但 SYS/BIOS 无法调用任何任务等 降级到 TI v7.4.16似乎没有效果。

我了解您忙于重要任务、我感谢您花时间研究此问题。

此致、
David Askew

PS：不确定是否重要、但我有一个非常基本的 AIS 启动映像刷写到我的 LCDK (通过 NANDWriter_DSP)、该映像只使 LED 闪烁。 我已在 zip 文件中包含映像"boot2.ais"、以防相关。

e2e.ti.com/.../PDI_5F00_Project.zip

我可以给...

[引用 user="David_Askew">在当前配置中，您将注意到 rts64plus_elf.lib 最后链接，导致对读取 ID 操作的"OOOO"响应。 请注意、当 rts64plus_elf.lib 完全从工程中删除时、此行为是相同的。 相反、如果您首先链接 rts64plus_elf.lib、则会观察到适当的"ONFI"响应、但 SYS/BIOS 无法调用任何任务、等等

如果您没有告诉链接器要使用哪个 RTS 库、链接器会自动为您选择一个库。

我可以考虑两种可能的原因、即您会根据链接器在命令行上看到 RTS 库的位置看到不同的行为。

第一、多个库中存在相同的函数、链接错误的函数。  要查看是否可能发生这种情况、请将选项--scan_libraries 添加到链接中。  如果多个库中存在相同的函数、您将获得一个诊断、其中显示哪些库具有该函数以及使用哪个库。  在 C6000汇编工具手册中阅读有关--scan_libraries 的更多信息。

第二、使链接器以不同的顺序查看输入会导致以不同的顺序将内容分配给系统内存。  这种差异可以屏蔽或解掩其他一些问题。  让我们希望情况并非如此、因为跟踪起来要困难得多。

谢谢、此致、

乔治

乔治

感谢您对--scan_libraries 的建议，这是一款方便的工具。 我注意到这两个版本之间有一些关键差异。

有三个符号–"_stack"、"_c_int00"和"_auto_init_elf"–根据链路顺序从不同的源中拉出。 在 rts64plus_elf.lib 最后链接的版本中、这些符号从"boot.ae674"中拉出、但在它首先链接时、这些符号从"rts64plus_elf.lib"中拉出。

还有许多符号从"rts64plus_elf.lib"而不是"rts6740_elf.lib"中提取、反之亦然。 不确定这是否重要、因为我想这两个库基本上是相同的。

在这两种情况下、"_stack"位于同一地址、"TI_stack_size"和"TI_STACKEND"也是相同的。 在两种情况下、入口点符号_c_int00具有类似的地址：c0055b80和 c0056d20。

也就是说、我不清楚这些符号中的任何一个会如何影响 EMIF 及其数据的处理方式。

至于#2、我已经比较了两个编译的.map 文件。 它们之间共用的模块按相同的顺序分配。 此外、具有有效 SYS/BIOS 的版本似乎包含其他.map 的所有模块和符号以及与 SYS/BIOS 相关的几个附加模块。 这一事实可能解释了任务和计时器在一种情况下无法正常工作的原因、但很难看出它可能与 EMIF 行为的变化有何关系。 有什么想法吗？

谢谢、

David

Rahul、

您是否有机会了解这一点？ 您是否需要任何其他文件？

[引用 user="Rahul Prabhu"]我可以将 NANDWriter 代码添加到任务中，并使用 TI RTOS 和 SYSBIOS 运行该代码，而不会出现任何问题

您的 NANDwriter 代码是否可以从 NAND 芯片中读取和写入数据而不会出现任何问题？ 如果可以、您能否在此处上传项目以便与我的项目进行比较？

谢谢、

David

Randy、

SYS/BIOS 自动包含"rts6740_elf.lib"。 我发现(在尝试使用 TI-RTOS 项目调试 NANDwriter 时)、如果我明确链接"rts64plus_elf.lib"(原始 NANDWriter 项目中使用的同一库)、我可以使 NAND 操作正常工作。

现在很容易错过、因为这个线程已经很长了、但我已经多次声明、无论我是最后链接"rts64plus_elf.lib"、还是完全不链接它、结果都是完全相同的。 下面的真值表应该对其进行汇总。

 我同意您的看法、这几乎肯定是不同库的问题、会导致不同的结果。 我的问题是为什么构建#3会导致 EMIF 与 NAND 相关的运行问题？ 此外、如果我无法访问库的源代码、我甚至会如何处理调试这样的问题？

[引用 user="RandyP"]...Rahul 解决方案的最佳方法是、如果可能、您可以创建失败文件集(以及可能单独工作的文件集)的 zip 存档项目、包括库文件和头文件以及所有本地源文件。 [/报价]

我向 Rahul 提供了该项目和所有相关文件。 此外、3月27日、我将所有内容重新打包成一个.zip 文件。 未包含的唯一文件是他应该已经具有的标准软件包、例如 MCSDK、CSL、XDCtools 和 TI-RTOS 本身。 这些软件包的数据容量高达几 GB，而且还是 Rahul 已经拥有的文件。 他只需更改项目的几个路径变量即可使其在自己的机器上工作。

还不清楚、尽管 Rahul 似乎声称已经使用 NANDWriter 代码创建了一个 TI-RTOS 项目、该代码能够正常工作。 如果是这样、那么他的示例项目的副本可能就是我从他的头发中取出来的全部内容！ 再次感谢您抽出宝贵的时间为您提供帮助。

此致、

David