[参考译文] TMDSCNCD280049C：如果使用修改的链接器命令文件、则器件在加电后唤醒"#39;t "。

您能详细说明一下"不起作用"是什么意思吗？ 他们能否判断它是否甚至达到了 main()？ 他们的项目中是否有 CodeStartBranch.asm (或自定义等效项)？

我没有在 cmd 文件中找到任何相关内容。 他们是否也想共享.map 文件？

惠特尼

尊敬的惠特尼：

非常感谢您检查.CMD。
您能否等待几天以获取地图文件。

此致、
Hitoshi  

尊敬的惠特尼：

这是随附的映射文件。
如果您能仔细研究并让我知道任何发现、我将不胜感激。

感谢您的调查。
此致、
Hitoshie2e.ti.com/.../fcl_5F00_f28004x_5F00_tmdxiddk.txt

感谢您提供.map 文件。 我仍然没有看到任何明显的错误。 你能回答我之前的问题吗——它以什么方式失败了？ 它是否到达 main()或无法引导？ 他们能否在代码中的关键点使 LED 闪烁或切换引脚以尝试确定中断位置？

惠特尼

尊敬的惠特尼：

感谢您的善意调查。
根据客户的说法、程序在通电后不运行。
对于调试、如果 XDS 连接到电路板并从 CCS 加载代码、则可以顺利运行。
但是、在 XDS 断开连接并再次为电路板通电后、程序不会唤醒。  
无 LED 闪烁等
他们很难检查是否正确调用 main()。

他们已经使用我们的 LED 闪烁示例代码进行了测试、程序运行正常。
因此、他们认为链接器命令文件设置不正确。

我认为最好使用我们的 LED 示例中的文件重新创建链接器命令文件、并通过简单的代码进行测试。
如果您有任何建议、这将非常有帮助。

再次感谢、致以诚挚的问候、
Hitoshi

尊敬的惠特尼：

客户将相应地调试他们的代码。
如果他们有任何其他问题、将在 e2e 上再次发布该帖子。

感谢您对.CMD 和.map 文件进行的友好检查。
此致、
Hitoshi

尊敬的惠特尼：

我当前正在调试。

我已绕过 GEL 文件(C28xx_CPU1)、但看不到代码停留在哪里。

您能告诉我如何找出代码被卡住的位置吗？

此致

Rui

连接到器件后、您在 CCS 调试视图中看到了什么？ 您至少应该能够查看程序计数器并找出它尝试执行的代码。 地址是什么？

您是否尝试为引导 ROM 和应用程序添加符号以获得更多详细信息？

惠特尼

感谢你的答复。

CCS Debug 透视图显示：
・调试
FCL_f28004x_tmsdxiddk[Code Composer Studio -器件调试]
德州仪器(TI) XDS100v2 USB 调试探针/CLA1_0 (断开连接：未知)

・拆卸
・・・・・・μ A ｜・・・μ A

未显示地址和程序计数器、我应该在调试视图中查看什么窗口？

在屏幕截图中、您实际上没有连接到器件。 您需要单击工具栏上的"连接"按钮。 连接后、您应该能够在"Debug"面板中查看地址、但也可以在"Registers"面板中打开"Core Registers"部分、并在其中找到 PC。

惠特尼

感谢你的答复。

当我单击"Connect"按钮时、CCS 软件会强制终止。

Code Composer Studio 的版本为"9.3.0.00012"。

每次都会发生这种情况？ 是否仅在没有 GEL 文件的情况下进行连接时发生、还是在执行常规调试时发生？

惠特尼

感谢你的答复。

它每次都会发生。 但是、仅当绕过 GEL 文件时。 在常规调试中不会发生这种情况。

我在使用"Bypass (旁路)"复选框时遇到了相同的问题。 我认为这只是绕过整个 CPU。 相反、取消选中它、只需清除"初始化脚本"文本框并保存即可。 如果 CCS 用"..\CCSTargetConfigurations"填充它是可以的-只需确保没有列出.gel 即可。

惠特尼

感谢你的答复。

相反、我取消选中它、清除"初始化脚本"文本框、保存它、然后尝试调试。

我无法使用以下错误开始调试。

"加载程序错误"
详细日志
C28xx_CPU1：警告：复位后解锁器件(区域1)失败。
C28xx_CPU1：警告：复位后解锁器件(区域2)失败。
C28xx_CPU1：设置断点时出现问题、在0xc0d4处执行"保持暂停"操作：(错误-1066 @ 0xC0D4)无法设置/清除请求的断点。 验证断点地址是否在有效存储器中。(仿真包8.4.0.00006)
C28xx_CPU1：断点管理器：使用 AET 断点重试
C28xx_CPU1：执行 PLL 配置算法时出错。 操作已取消。 (0x0)
C28xx_CPU1：在擦除/加载闪存之前、执行调试器复位并执行引导 ROM 代码(点击 CCS 调试窗口中的"恢复"按钮)。如果这无助于成功执行闪存擦除/加载、请检查复位原因(RESC)寄存器、 NMI 影子标志(NMISHDFLG)寄存器和引导 ROM 状态寄存器、用于进一步调试。
C28xx_CPU1：文件加载程序：内存写入失败：未知错误
C28xx_CPU1：GEL：文件：C：\Users\FCL_f28004x_tmdxiddk\FCL_f28004x_tmdxiddk.out：加载失败。

您是否使用 Debug 按钮开始调试？ 我们希望在不加载程序的情况下连接到器件、因此我们需要以不同的方式执行该操作。

您能否在 CCS 中打开目标配置视图并在列表中找到编辑过的 CCXML？ 右键单击它并选择"Launch Selected Configuration"、然后单击"Connect"按钮。 正如我之前所说的、您不想加载程序、但可以使用"Load"->"Add Symbols"来获取更多调试信息。

惠特尼

感谢你的答复。

到目前为止、我通过按下调试按钮开始调试。
我附加了一个映像、但即使我右键单击编辑过的 CCXML、也不会显示项目"启动选定的配置"、并且无法启动连接。
这是 CCS 版本问题吗？

该选项不会出现在 Project Explorer 视图中-您只能在 Target Configurations 视图中看到它。 我可以在屏幕截图右侧看到它的选项卡。

惠特尼

感谢你的答复。

我能够连接到目标。 非常感谢。

连接后连接捕获。
它在地址3fc7a5停止、并显示消息"no symbols are defined"。
当我从这个状态"恢复"时、它似乎在地址3fb02a [ESTOP0]上停止。

我认为我无法从引导加载程序转到主程序。 分析应如何进行？

您的 GEL 文件看起来仍在使用(请参阅控制台消息)、因此您的器件在连接时会复位、这就是它指向0x3fc7a5 (引导 ROM 代码的开始)的原因。 我们不希望它被重置、因为我们会失去它被卡住的位置。 基本上、我要查看的过程是

1.在器件断开连接的情况下、对电路板进行下电上电、使其独立启动

2.将其连接到 CCS、同时删除 GEL 文件、因此不会发生复位并保留器件状态

3.查看应用程序在独立启动期间的停滞位置，加载符号(仅限符号，而不是整个程序)以帮助进行调试

原始文章指出、闪烁 LED 示例已正确引导。 您能否确认、当您进行该实验时、您使用的是项目的闪存构建配置？ 请仔细检查是否已为闪存引导模式配置引导模式引脚。

惠特尼

感谢你的答复。

很抱歉、似乎已重置、因为我启动时选择了不同的 CCXML。 在连接到器件时、删除 GEL 文件并附加捕获。 它卡在0x3fb02b 上。

已完成"加载符号"、将显示"未定义符号"。

闪烁 LED 示例使用了闪存构建配置
引导模式引脚对于 BOOT_0和 BOOT_1都是"高电平"。

谢谢、这就是我要找的。 因此地址0x3fb02b 是等待引导模式的一部分。 您似乎已为闪存引导正确配置了引导引脚、但有时在引导过程出错时会输入等待引导。

我注意到在先前共享的.map 文件中、boot_RSVD 区域似乎加载了一些内容。 我不认为这是问题的原因、但我想提醒一下、该区域中放置的任何数据在复位时都将被引导 ROM 覆盖、因此请确保这不是问题。

我仍然不清楚它是否永远不会到达 main()。 我想知道它是否到达 main()、得到复位、然后返回到引导 ROM 中，或者它是否从不到达 main ()。 您是否通过在 main()的开头添加代码来切换引脚来确认此操作？

惠特尼

感谢你的答复。

我检查.map 文件中的 boot_RSVD 区域。

我认为我没有先到达 main()。
原因是，当我在 main()和 while 循环之间添加了代码“切换引脚”时，波形没有发生任何变化。

我们似乎需要调查启动过程有问题的原因。

顺便说一下、这次我将在"C：\ti\c2000\C2000Ware_MotorControl_SDK_2_01_00_00\solutions\tmdxiddk379d\f28004x"中编辑示例程序并对其进行检查、但不进行编辑的示例程序可以正确启动。 不是吗？

如果可能、您可以在您的环境中测试它吗？

感谢您调试原始应用。

将应用程序中 f28004x_codestartbranch.asm 文件中的 WD_disable 从0更改为1也解决了这个问题！

顺便说一下、这个看门狗复位问题是否是由初始化符号所需的时间引起的、如以下 URL 中所示？

e2e.ti.com/.../3314206

此外、我禁用了看门狗。 如果我在用户应用程序中再次启用它、是否正常？

很高兴听到这是问题的根源。 是的、您链接到的线程中给出的说明是准确的。

是的、您可以在应用程序中重新启用它。 当前 Device_init()无论如何都会禁用它，但如果您计划添加为看门狗提供服务所需的函数调用，则该操作将起作用。

如果您希望在 c_int 期间将其保持打开、您还可以考虑编辑 CodeStartBranch.asm 文件以写入 WD 分频器、以将其减慢到足够快的速度、从而不会超时。

惠特尼

感谢你的答复。

发现了原因，非常好。谢谢。
目前、我的应用不使用看门狗、因此我将在需要时在应用中启用看门狗。
在 c_int 期间，如果需要看门狗，我会编辑 CodeStartBranch.asm 文件。 如果是、我应该如何在 WD 分频器中编写代码？

感谢你的答复。

在名为"WD_DISABLE"的部分中、我能够确认 WDCR 寄存器的 WDDIS 位被清零。 值"#0068h"被写入这里。 我将重写对应于 WDCR 寄存器11-8位的设置、以降低时钟速度。

所有问题均已解决。

感谢您长时间关注我。