[参考译文] CCS/TMS320F2.8069万：加载cinit失败导致低功耗模式

标记

感谢您的回复。 为了回答您的问题，我可以通过将设备连接 到 调试器来确定它处于低功耗模式。 它产生的错误与您在上面描述的错误完全相同。

退出低功耗模式的唯一方法是拔下用于 确定开机启动模式的GPIO引脚之一。 之后，我可以使用JTAG端口加载。

Syed

Syed，

您收到此错误是因为CCS无法连接到设备。 低功耗模式只是一种可能的情况。 当设备访问安全内存时，当ECSL跳闸JTAG连接时，您也会收到此错误。 您的ECSL密码(8字节CSM密码的一部分)是否已编程？

此致，

Manoj

Manoj

首先，我无法确定在 发生此错误时，ECSL是否正在进行电源循环编程。 问题是，当出现该错误时，我无法使用调试器来确定它是否已成功解锁。

其次，我要强调，即使我不使用JTAG，也会发生此问题。 也就是说， 当与计算机的唯一连接是串行连接(SCI)时，就会发生这种情况。 如果我在闪存内核加载cinits时中断此通信，然后重启主板，我无法使用串行连接重新连接到主板。 但是，如果我在任何其他时间中断通信，例如当闪存内核加载十六进制文件的.text部分时，我仍然可以在关闭电源后使用串行连接连接到设备。 此外，使用bootloader完全加载程序后，无论我重启设备多少次，它都不会进入低功耗模式。

因此，我认为闪光灯不会被锁定。 毕竟，它实际上是锁定了设备， 它每次都应该这样做，即使bootloader成功地将代码加载到闪存中也是如此。  此外，我检查了我的代码，并且没有使用密码来锁定闪存(密码仍设置为defaut FFFF)。

基本上，在我看来，芯片中有一个错误，如果没有填充cinits，设备将进入低功耗模式。 当它执行此操作时，我无法重新尝试引导加载程序。 尽管我知道如何使其脱离低功耗模式(拔下 用于确定启动模式的GPIO引脚之一)，但我的大多数设备用户都不知道如何执行此操作。  此外，此设备的用户将无法访问JTAG端口。

我的问题是：如何确保 F2.8069万 不会进入低功耗模式，即使 没有完全填充cinits？

Syed  

Syed，

设备不应仅因为在.cinit十六进制代码过程中通信中断而进入低功耗模式。 我的理解是，您声称设备处于低功耗模式，因为CCS在连接时报告为低功耗模式。 您是否检查了VDDIO/VDD上的电源电流以确认您是否处于低功率模式？ 如果电源电流没有下降，则确认设备处于低功耗模式还为时过早。

另外，ECSL密码是CSM密码的一部分，我们需要知道在Sector-A的最后八个位置(0x3F7FF8 - 0x3F7FFF)中编程了什么。 连接到锁定设备上的CCS的一种方法是使设备处于等待引导模式。 您可以通过将GPIO37设置为高，GPIO34设置为低，使设备处于等待引导模式。 连接到设备后，请提供0x3F7FF8 - 0x3F7FFF的内容。

此致，

Manoj

Manoj

很抱歉未能尽快回复您。 当我中断启动加载程序时，它正在将煤渣加载到闪存中，然后再重新启动，主板总共消耗了48mA的电流。 明确地说，这是我无法使用引导加载程序或JTAG端口将代码重新加载到闪存的情况(启动时操作GPIO34和37除外)。

关于 第二点， 在将主板置于等待启动后，我发现所有八 个位置都有FFFF。 这与 错误不 存在且引导加载程序成功时的正常情况匹配。

这两种结果似乎相互矛盾。  由于电流消耗较高，它似乎不太可能处于低功率模式。 但是，我 怀疑闪存是否已锁定，因为密码与通常的密码没有什么不同。

除了低功耗模式或 锁定的设备之外，是否还有其他任何可能生成该错误代码的设备？

谢谢。

Syed  

Manoj

1.代码的任何部分都不会擦除闪存扇区A。闪存内核擦除除扇区A以外的所有扇区。在任何情况下，都不应擦除扇区A。 由于它包含启动引导加载过程的代码，因此永远不应将其擦除。 另外，十六进制文件在扇区A内不包含地址。我是通过进入C2000十六进制实用程序的属性并 在链接器命令文件中列出与 扇区A地址对应的部分来实现这一目的的。   然后，当CCS生成十六进制文件时，此功能将从十六进制文件中排除这些部分。  因此，假设某种东西正在擦除闪存扇区A，即使引导加载程序成功，它也永远不会启动。 这种情况没有发生。 当引导加载程序成功时，应用程序代码和电路板的运行正常，就像使用JTAG和CCS下载一样。

我还应该注意，当闪存内核擦除完毕后，它会向主机发送一个特殊字符，表示已擦除闪存。 只有这样，主机计算机才会尝试发送需要在闪存中编程的数据。

2.我已经检查了引导加载程序成功时和出现错误时的两种情况的闪存。 引导加载程序成功时，闪存将与项目中指定的内容匹配。 当发生错误时，它会显示不一致发生在电影的地址范围内。 闪存扇区A仍匹配。

3.电影始终位于十六进制文件的开头。 cinits的起始地址和范围在链接程序命令文件中指定。 我还对链接程序命令文件进行了排列，以便生成十六进制文件时，电影始终排在第一位。 每当我重建项目时，我还会手动打开十六进制以检查并确保情况确实如此。

4.正常开机时，它应等待检测来自主机的串行数据。 如果没有任何反应，则应转到应用程序代码。 但是，当错误发生时，开机时，它甚至不会尝试查找串行数据。 我知道这是因为我激活了主板上的一个LED，它在引导加载程序等待期间保持亮起。 该代码等待7秒钟，然后转至应用程序代码。 但是，在开机时，LED甚至不会亮起。  在_c_init00中发生了一个事情，当cinit表不完整时，它将进入这种状态。 我的猜测是，当端点零未编程到中时，它可能会将0xFFFFFFFF解释为内存位置。 当它尝试转到此位置时，会发生错误，因为它显然不是内存映射的一部分。 我没有rts2800_fpu32的源代码，因此我无法确定。 但是，我确实可以访问rts2800_BL (从controlSUITE)，它看起来像是基于boot28.asm的汇编代码。这可能是可能的。

5.发生错误时，无法单步完成此操作。 我尝试过很多次，但似乎不可能。 即使我将其置于等待启动状态，CCS允许我做的只是检查闪存。 我无法逐步执行代码。

基于所有这些，我认为可能有两个变通办法：

选项1：在闪存内核中，擦除扇区B-H后，但在开始加载cinits之前，在紧位于cinits内存范围之后的内存范围中添加零。 这样，即使cinits没有完成加载，引导例程仍将看到它认为是端接零的内容。  我可以修改链接程序命令文件，以确保零所在的位置没有cinits (即不要尝试写入未擦除的地址)。  这在理论上应允许行李箱完成，并将手控板置于闪存代码的开始部分。 这将允许用户在启动时重试引导加载程序。

选项2：如果我可以保留rts2800_fpu32，我可以修改汇编代码的cinit部分，使其在闪存范围之外时不使用地址(例如不存在的地址 0xFFFFFFFF)。  然后我可以使用此库代替正常的rts2800库。

Syed  

Syed，

rts2800_fpu32的源文件可在以下路径中找到：-

<ccsv6>\tools\compiler\latest-compiler-version\lib

此致，

Manoj