[参考译文] TMS320F28379S：C2000ware 中的使用 SCI 引导加载程序进行串行闪存编程时出现问题示例

您好、

一些建议：

-如果你想使用 SCI 引导模式 与独立加载的内核,你应该使用 serial_flash_programr.exe  

-检查是否为 SCI 通信设置了正确的 GPIO

-内核与哪些 GPIO 通信?

谢谢、

Charles

尊敬的 Charles：

• SCI 引导模式和串行闪存编程器
  我已尝试使用" serial_flash_programmer.exe"正如您建议的那样、但问题仍然是一样的。 此外、我还尝试了降低波特率、但这也无法解决问题。

•  引导模式的 GPIO
  引导模式设置为 SCI、GPIO 72设置为0、GPIO 84设置为1、以进行 SCI 通信。

• SCI 通信引脚
  我已经验证了 SCI 引脚(GPIO 28和29)的代码和硬件、所有内容似乎都井然有序。 我还确认使用终端软件进行测试时 SCI 通信有效。

  请建议我如何继续。

  谢谢

您好、

这可能是 GPIO 不匹配导致的。 GPIO 28和29用于备用 GPIO 引脚、 默认为 GPIO 84和85。 您是否可以：

1)将 GPIO 28和29的器件设置为 EMU 引导模式

2)在 CCS 中运行 CPU1目标、然后使用"serial_flash_programmer.exe"以及使用的参数：

serial_flash_programr.exe -d f2837xS -k F2837xS_sci_flash_kernel.txt -a LED_blink.txt -b 115200 -p COM9

如果用户希望使用此模式正在使用的 GPIO 84/85、则必须在工程的源文件中编辑闪存内核以实现这些 GPIO 选择。

谢谢、

Charles

您好、

  请解释 GPIO 错误。

在硬件中、我连接了  GPIO 引脚72和84 、如 SCI 模式的数据表所示。对于1、我连接到3.3V、对于0 、我连接到 GND。

2.在示例代码中、我选择了如下所示的引脚28和29、因为引脚84属于引导模式控制引脚

根据数据表、GPIO 引脚72和84是引导控制引脚。 如何 为 GPIO 28和29设置 EMU 引导模式。

您好、

默认情况下、器件引导 ROM 使用 GPIO 84和85进行 SCI 通信。

您还可以为 GPIO 28和29设置 EMU 引导模式。 您是否可以尝试使用为 GPIO 28和29设置的 EMU 引导模式加载、 不需要考虑引导模式选择引脚、因为器件将在 CCS 中通过 JTAG 连接。

谢谢。此致、

Charles

尊敬的 Charles：

我尝试了您建议的步骤、但仍面临一些问题：

1. 我正在使用的器件 GPIO 28和29  构建步骤。
2. 最初、我连接了 XDS110 更多。
3. 设置为的输入电流  调试模式 然后,我就走了,走了出去 模式 配置。
4. 我尝试了修改 Z1_BOOTCTRL 如屏幕截图所示。
5. 自动进入 0x5A810010 设置模式、然后按 Enter 、值没有变化。
6. 另一种方法、我尝试了 修改 中的特定寄存器 表达式  窗口、值没有改变。

您能否确认我的程序是否正确？ 如果可以、请建议如何继续。

谢谢！

您的降价或当前波特率是多少？  

我应该添加一点、为了进入该器件的仿真引导模式、  C2000微控制器串行闪存编程 应用手册的第7.3.2节对此进行了说明。  

0xD00位置应在 Memory Browser 中包含值0x815A。

Z1_BOOTCTRL 值只能通过闪存 API 对 OTP 进行编程来修改、如果您希望首先成功执行仿真模式、并不是必需的。

您好、
我遵循了下面提到的步骤、但最后遇到了一个问题：

我从 Code Composer Studio 中的 SCI_Flash_kernel 示例代码进入调试模式。
2.我暂停操作并打开内存浏览器。
在存储器浏览器中、我搜索了0x1D00、并将第一个元素更新为0x815A。

然后、我运行了-> CPU 复位。
5.我按了播放按钮。
6.我从命令提示符运行命令。

serial_flash_programr.exe -d f2837xS -k F2837xS_sci_flash_kernel.txt -a LED_Blink.txt -b 115200 -p COM9"

7.闪存内核被转储。
8.i 为 DFU 选择了选项1。

9.应用程序代码被转储并要求下一步,我选择了选项6 来运行。

10.然后它要求地址分支到。
11.I 复制了上面的入口点地址并粘贴在下面。

12.过程得到 卡住 AT "正在调用 f021_SendPacket"。

如何解决此问题？

我也尝试了使用 GPIO 引脚设置 SCI 引导模式来尝试此方法、但它也不起作用。 请建议我如何继续。

您能否在内核通过 CCS 运行时为其加载符号？ 通过这种方式、我们可以更密切地看到 SendPacket 函数发生了什么情况。

尊敬的 Charles：

尽管这个过程会卡住 "正在调用 f021_SendPacket" ,我能够通过重置控制器验证我的应用程序代码是否已通过 SCI 成功上传到闪存。

但是、我主要担心的是、当在不使用仿真引导模式的情况下使用 SCI 引导模式时、该过程在第一次传输之后不会继续进行。

在终端中运行以下命令时：

"serial_flash_programmer.exe -d f2837xS -k F2837xS_sci_flash_kernel.txt -a ups-gpio.txt -b 9600 -p COM9"  

该过程停止于：

"calling f021_DownloadKernel CPU1 Kernel  
Downloading F2837xS_sci_flash_kernel.txt to device...  
aa  "

它不会继续下去。

遵循的步骤：

1. 已使用 F2837xS SCI_SCI Flash_Kernel 中的示例代码 C2000Ware 并对其进行了修改、以便使用备用引脚进行 SCI 通信。
2. 使用上传了修改后的代码 CCS 中完成 。
3. 已连接 SCI 引脚 连接到 PC。
4. 已运行命令。
5. 但是、这一过程在第一次传输之后没有继续进行。

您能帮助我解决这个问题吗？

Rajamurugan,

请参阅 TMS320F2837xS 实时微控制器技术参考手册(修订版 I)的表4-24。 引导 ROM 中 TX/RX 的默认 GPIO 为84和85。

当您使用仿真引导通过 GPIO 28+29加载内核时、您可以通过修改存储在0xD00处的值手动覆盖此设置。 这在电源复位过程中不会持续存在。 要永久更改它、您必须将 OTP BMODE 值设置为0x81、如表中所列。

另一种选择 是 使用 GPIO 84和85。

此致、

Alex

您好 Alex、

       在使用备用引脚时、我在 SCI 引导模式方面遇到了问题。

问题：使用带有备用引脚的 SCI 引导模式(修改示例代码后)时、该过程在第一次传输之后不会继续进行、它会卡在该点。

我遵循的步骤：
                1.修改了示例代码  "F2837xS SCI_FLASH_kernel"  中导出  C2000Ware  使用  备用引脚  如下所示：
                             指定  F2837xS sci_flash_kernel.c 、我将代码更新为：
                              "EntryAddr = SCI_GetFunction (SCI_BOOT_ALTERNATE)；"

                使用 CCS 上传了代码(此后我没有执行任何电源复位)。

                将 MCU 的 SCI 引脚连接到 PC。

                4.ran 以下命令：

                              serial_flash_programr.exe -d f2837xS -k F2837xS_sci_flash_kernel.txt -a ups-gpio.txt -b 9600 -p COM9"  

                5.然而,该过程没有在第一次传输之后进行

                                "调用 f021_DownloadKernel CPU1内核
                                正在将 F2837xS_sci_flash_kernel.txt 下载到器件...
                                AA"

 如果是、我是否需要设置 OTP BMODE 值如何设置该值。  

另一个问题是 、如果我需要 按照您建议的方式使用默认的84和85引脚、我如何将默认的引导模式选择引脚(84和72)更改为其他某个值。 例如 、如何  将引导模式选择引脚从72和84更改为3和2。

我的终极目标是首先将引导选择引脚设置为 sci 模式并上传固件、然后将引导选择引脚设置为闪存模式、以便在需要固件更新时始终从闪存引导。我可以将它们物理更改为 sci 模式。

请帮助我解决这个问题

Rajamurugan,

您可以更改引导模式选择引脚或 SCI 引脚、使它们不发生冲突、两者都需要对 OTP 进行编程。 这可以通过使用闪存 API 来完成。 要更改和/或配置引导选择引脚、请参阅 TMS320F2837xS 实时微控制器技术参考手册(修订版 I) 第4.5节、要更改 SCI 引脚、请参阅第4.10.6节。

对于您当前的问题、即使使用仿真引导正确、也会发生这种情况？  您能否确认器件上正在运行内核？ 通过 CCS 加载后、您能否暂停程序并检查它是否处于自动波特率？

此致、

Alex

您好 Alex、

否、使用仿真引导模式时、在执行最后一步之前、一切都正常。 选择 DFU 选项时、系统会加载应用程序代码、并提示我执行下一步。 选择选项6以运行。

然后、它要求分支到的地址。 我从上面复制入口点地址、并根据需要粘贴。

此时、该过程会卡住 "正在调用 f021_SendPacket。"

即使该过程尚未完成、在我将 MCU 复位时、它也会从闪存成功引导并运行应用程序代码。 因此、仅当我使用 XDS110调试器转储代码并执行前面提到的步骤(修改上述代码)时、才会发生此问题。

请帮助我解决为什么它不会超越第一次传输。

我还有一个问题::-平均时间我决定使用 GPIO 3和2作为引导模式选择引脚,而不是72和84以避免在 SCI 操作期间发生冲突。

 是否有任何详细的示例代码或应用手册可以通过对 OTP 进行编程来更改引导模式选择引脚？

Rajamurugan,

您能否通过在调用主机编程器时添加"-v"选项来启用详细模式？

此致、

Alex

您好 Alex、

是的、我可以通过在末尾添加"-v"来启用详细模式 我附上了结果的图像

在我第一次尝试时、它卡在第一次传输时、在我第二次尝试期间、自动波特锁回波出现错误。  

如 有 任何详细的示例代码或应用手册可通过对 OTP 进行编程来更改引导模式选择引脚、敬请分享。

Rajamurugan,

没有任何用于对引导模式选择引脚进行编程的示例工程、最佳基准是闪存编程示例  、您可以对其进行修改、以将写入 所需的 OTP 范围。  TMS320F2837xS 闪存 API 参考指南(修订版 A) 对此也很有帮助。

我仍在努力复制这一点、希望明天或下周初能做出更深入的回应。

我还想确保我理解正确、并且您看到了两个不同的问题：

• 使用仿真引导(无电源复位、通过 CCS 加载内核)时、内核在调用 f021_SendPacket 时挂起
• 从 SCI 引导时(电源复位后)、器件在上传内核时无法自动波特、随后会挂起。  它失败的点并不一致

此致、

Alex

您好 Alex、

Unknown 说：

使用仿真引导(无电源复位、通过 CCS 加载内核)时、内核在调用 f021_SendPacket

您对此问题的理解是正确的。

但是、

响应

Unknown 说：

从 SCI 引导时(电源复位后)、器件在上载内核时无法自动波特、随后挂起。  失败的点不一致

我确实从 sci 引导、但在此之前、 我使用 CCS 上传了修改后的代码、以便为 sci 分配备用引脚。

我在下面提到的步骤

 1.修改了示例代码  "F2837xS SCI_FLASH_kernel"  中导出  C2000Ware  使用  备用引脚  如下所示：
                             指定  F2837xS sci_flash_kernel.c 、我将代码更新为：
                              "EntryAddr = SCI_GetFunction (SCI_BOOT_ALTERNATE)；"

                使用 CCS 上传了代码(此后我没有执行任何电源复位)。

                将 MCU 的 SCI 引脚连接到 PC。

                4.ran 以下命令：

                              serial_flash_programr.exe -d f2837xS -k F2837xS_sci_flash_kernel.txt -a ups-gpio.txt -b 9600 -p COM9"  

                5.然而,该过程没有在第一次传输之后进行

                                "调用 f021_DownloadKernel CPU1内核
                                正在将 F2837xS_sci_flash_kernel.txt 下载到器件...
                                AA"

希望这对我有所帮助、感谢这里的帮助！

Rajamurugan,

对于第二个问题(自动波特率问题)、请尝试使用 serial_flash_programmer_appln.exe。 由于内核已经被 CCS 放入 RAM 中、因此该版本仅通过 SCI 发送该应用。

我仍在研究第一个问题。

此致、

Alex

您好 Alex、

您能帮我解决这个问题吗？

我尝试了您提到的步骤、应用程序成功加载到闪存。 但是、内核会在 f021_SendPacket 处挂起、这与在仿真模式下观察到的问题相同。

我目前正在实施闪存 API 以更改引导模式选择引脚。

BMSP0：从 GPIO 84更改为 GPIO 73
这将允许我使用默认的 SCI 引导模式引脚(GPIO 84、GPIO 85)进行固件更新。

最终要求：
在正常操作下、MCU 应始终从闪存引导。
当需要固件更新时、我会将引导模式选择引脚设置为 SCI 模式、更新固件、然后将它们设置回闪存模式。
电源复位后、除非手动设置为 SCI 模式进行更新、否则 MCU 应始终从闪存引导。

主要问题：
根据我的理解、如果我正确配置了引导模式选择引脚、我应该能够使用 serial_flash_programmer.exe 成功加载内核和应用程序代码。
而无需使用 JTAG 和 CCS？

您能否确认我的方法是否正确？

Rajamurugan,

是的、如果正确配置和选择了 GPIO 和引导模式、您将能够通过 SCI 加载内核和应用程序代码。

您可以尝试将波特率降低到100K 以下吗？

如果这样做不起作用、您是否可以通过 CCS 加载内核并完成正常加载过程 、直到 f021_SendPacket、然后在 CCS 中暂停内核。  它在哪里卡住了？

此致、
Alex

您好 Alex、

Unknown 说：

是的、如果正确配置和选择了 GPIO 和引导模式、您将能够通过 SCI 加载内核和应用程序代码。

我需要修改 "BMSP0：从 GPIO 84更改为 GPIO 73"   但在修改(写入 OTP)之前、有任何方法可以检查其在仿真引导模式下的工作情况。

如果是、建议如何操作。

Unknown 说：

您可以尝试将波特率降低到100K 以下吗？

我厌倦了波特率 9,600,19200 结果相同、但误差没有改善

Unknown 说：

如果不起作用、您是否可以通过 CCS 加载内核并完成正常加载过程 、直到 f021_SendPacket、然后暂停 CCS 中的内核。  它在哪里卡住了？

然后、按照建议、我已在调试模式下使用 CCS 上传内核代码以播放和暂停代码  

我运行了下面提到的命令

serial_flash_programr_appln.exe -d f2837xS -k F2837xS_sci_flash_kernel.txt -a ups-gpio.txt -p COM8 -b 19200 -v"

当该进程在 f021_SendPacket 挂起时、我暂停了代码和我附加在下图中的结果  

请做必要的事情

Rajamurugan,

要测试您的 OTP 配置、请参阅 TMS320F2837xS 实时微控制器技术参考手册(修订版 I)的第4.5节和表4-6。 除了模拟引导模式之外、您还可以测试引导模式选择引脚更改。

在 f021_SendPacket 之后、是否可以尝试发送第二个运行命令(键入6、然后键入 Enter)？ 如果没有任何效果、您能否展示 SCI TX 和 RX 缓冲区的内容(可在寄存器视图中找到)。

此致、

Alex

您好 Alex、

很抱歉、延迟的回复

下面是根据要求进行的 SCI TX 和 RX 缓冲器内容的屏幕截图。

Rajamurugan,

我今天终于重新创建了这个问题、并将尝试尽快找到解决方案。 在此期间、您能否分享您的呼叫堆栈图片？

此致、

Alex

您好 Alex、

我尝试了您建议的输出得到满足。 我已将输出连接到以下位置。

但是、我在使用实际应用代码时遇到了一些问题、上面的步骤是使用简单的 LED 闪烁代码完成的。

我已经附上了供您参考的屏幕截图。

请帮助我了解如何继续。

您好 Alex、

下面是我在代码中所做的修改、如果我错了、请更正我

//28379S_FLASH_lnk.cmd
//Line numbers mentioned below 

0: .cinit              : > FLASHB      PAGE = 0, ALIGN(8)  
81: .pinit              : > FLASHB,     PAGE = 0, ALIGN(8)  
82: .text               : >> FLASHB | FLASHC | FLASHD | FLASHE      PAGE = 0, ALIGN(8)  
83: codestart           : > BEGIN       PAGE = 0, ALIGN(8)  
95: PAGE = 0, ALIGN(8)  
105: PAGE = 0, ALIGN(8)     
115: .econst             : >> FLASHF | FLASHG | FLASHH      PAGE = 0, ALIGN(8)  
116: .switch             : > FLASHB      PAGE = 0, ALIGN(8)  

输出不符合预期、应用程序代码未加载到闪存中。

进程如下图所示挂起  

您好 Alex、

 我误使用了.out 文件而不是.txt 文件。

现在它可以正常工作。

我在 OTP 存储器编程方面需要其他帮助

我尝试了 EMU 引导模式以测试 BMSP 中的变化

我尝试使用  0xFE5A (对于0xD00)和0x004A (对于0xD01)、但它不起作用。

我的要求是将 BMODE 设置为 SCI、将 BMSP0设置为73  

Rajamurugan,

抱歉、我之前出错了、该器件上不提供引导模式选择引脚仿真、您必须对 OTP 区域进行编程。

BOOTCTRL 寄存器位于地址 0x7801E、应使用以下字进行编程： 0x5A0B 0x49448 0xFE5A  0x0049。 这将设置 BMSP0 = GPIO73、BMSP1 = GPIO72、并将默认引导模式设置为读取引导模式选择引脚。

请注意、为了正确计算 ECC 值、闪存 API 在编程时至少具有64位、因此缓冲区可能需要包含一些周围的存储器。

此致、

Alex

您好 Alex、

Unknown 说：

您可以尝试在 SCI_GetFunction.c 中的函数 SCI_GetFunction 的 while 循环底部插入 no-op 吗？

即使命令在没有任何挂起的情况下结束、但是 完成此步骤后、代码未从闪存运行  

请帮我解决这个问题

Rajamurugan,

命令结束后、LED 闪烁示例是否也无法运行？

另外、我看到了您之前的响应(不确定它在哪里)、您是正确的-有用于模拟引导模式选择引脚的寄存器。  

尝试使用0xD00 = 0xFE5A、0xD01 = 0x549。

此致、

Alex

您好 Alex、

是 LED 闪烁示例也无法运行。

我已使用值成功仿真 BMSP FE5A 和004A 但我的怀疑是

1.什么 数据值  我需要  向写入  Z1_BOOTCTRL OTP 中使用 调试中的"Chip"菜单。

根据 EMU 引导模式的结果、该值为   0x004A 0B5A  

但 我注意到默认值是 0xFFFFFFFF 根据这一点、我假设该值将是  0xFF4A 0B5A  

请告诉我正确的值、以便我可以尝试对 OTP 存储器进行编程




请告知我无法运行的解决方案以及 寄存器的正确值。

尊敬的 Rajamurugan：

我看到 您有两个正在进行 的主题讨论相同的主题。 我将关闭另一个主题、解决您关于该主题的问题。

Unknown 说：

但 我注意到默认值是 0xFFFFFFFF 根据这一点、我假设该值将是  0xFF4A 0B5A  [/报价]

这不正确。 由于您需要 BMSP0 = GPIO73且 BMSP1 = GPIO72、因此您要将 BOOTCTRL 配置保持为 0x004A 0B5A 。  '00'将使 BMSP1保持其默认配置(GPIO72)、但'FF'将其设置为 GPIO255。

Unknown 说：

尝试使用0xD00 = 0xFE5A、0xD01 = 0x549

此配置将使器件读取仿真 BMSP、但当选择获取模式时、使用 OTP BOOTCTRL 寄存器中的引导模式(如果已编程)。  

Unknown 说：

1. 数据值  我需要  向写入  Z1_BOOTCTRL OTP 中使用 调试中的"Chip"菜单。 [/报价]

您将需要进行编程 0x004A 0B5A 进入 Z1-BOOTCTRL、以配置 BMSP0 = GPIO73、BMSP1 = GPIO72、BMODE =引导至闪存。 然后、您可以通过启用获取模式(将 BMSP0和 BMSP1都设置为1)将器件引导到闪存。

此致、

马特

[/quote]

尊敬的 Matt：

感谢您的答复！  

我成功使用了0x004A 0B5A、工作正常、符合预期。

Unknown 说：

命令结束后 LED 闪烁示例是否也无法运行？

但这个问题仍然存在、请为这个问题提供解决办法。

尊敬的 Rajamurugan：

查看应用程序的链接器命令文件、您似乎将其放置在 FlashB 中、即0x082000。 但是、闪存引导(0x0B)入口点地址为0x80000。 为了使器件成功引导至您的应用程序、您需要将应用程序置于闪存入口点0x80000。

此致、

马特

尊敬的 Matt：

/*Exsisting*/

/* Flash sectors */
FLASHA           : origin = 0x080002, length = 0x001FFE	/* on-chip Flash */
FLASHB           : origin = 0x082000, length = 0x002000	/* on-chip Flash */
   
/* Allocate program areas: */
.cinit              : > FLASHB      PAGE = 0, ALIGN(8)
.pinit              : > FLASHB,     PAGE = 0, ALIGN(8)
.text               : >> FLASHB | FLASHC | FLASHD | FLASHE      PAGE = 0, ALIGN(8)
codestart           : > BEGIN       PAGE = 0, ALIGN(8)

/* Initalized sections go in Flash */
.econst             : >> FLASHF | FLASHG | FLASHH      PAGE = 0, ALIGN(8)
.switch             : > FLASHB      PAGE = 0, ALIGN(8)



   
/*Modified*/

.cinit              : > FLASHA      PAGE = 0, ALIGN(8)
.pinit              : > FLASHA,     PAGE = 0, ALIGN(8)
.text               : >> FLASHA | FLASHB | FLASHC | FLASHD      PAGE = 0, ALIGN(8)
codestart           : > BEGIN       PAGE = 0, ALIGN(8)

.switch             : > FLASHA      PAGE = 0, ALIGN(8)

我在这里附加了我现有的和修改过的代码。

这是正确的吗？ 还是 需要进行其他一些更改。

我尝试了这个,它不能正常工作。

1.请提供一些详细的见解和步骤。

如需了解相关信息、我尚未对链接器文件进行任何更改、因此默认情况下会转到闪存 B。 因此、将来我需要进行所有这些更改才能使 SCI 引导加载程序正常工作、或者在初始配置时可以执行任何操作。  

您好、

您是否也将 codestart (begin)修改为0x80000？ 如果是、请将用于构建的.map 文件发送给我、以便查看应用程序的加载位置。

Unknown 说：

2.如需了解相关信息、我尚未对链接器文件进行任何更改、因此默认情况下、它会转到 FLASH B。 因此、将来我需要进行所有这些更改才能使 SCI 引导加载程序正常工作、或者在初始配置时可以执行任何操作。  [/报价]

您能重新澄清一下吗？ 我不确定我是否完全理解。

此致、

马特

您好、

我没有更改链接器文件、因此默认情况下放入代码 FLASH B 对吧？

将来、我是否总是需要修改链接器文件以使 SCI 引导加载程序正常工作、或者是否有办法从一开始就正确配置它？

只要应用程序的 codestart 为0x0008 0000、应用程序就应该成功引导至。 映射文件确认了这种情况、并且通用闪存链接器命令文件已经设置为执行此操作、因此将来无需修改。

我不知道是否会出现这种情况、因为您提供的链接器命令文件片段省略了 codestart 的位置、仅显示了应用程序的加载位置。

Unknown 说：

我尝试过这种方法、但它无法正常工作。

当您提到应用程序不工作时、是否意味着在复位时引导至闪存？ 或在 serial_flash_programmer 完成应用程序编程后的状态。

此致、

马特

要求：-需要在 通过 sci 引导加载程序完成命令后运行应用程序代码

Unknown 说：

如果您说应用程序无法正常工作、那么是否意味着重置时引导至闪存？ 或在 serial_flash_programmer 完成应用程序编程后。

来自 Serial_flash_programmer 的所有命令都完成后、应用程序代码无法运行。 仅在我切换至获取模式并重置 MCU 时才起作用。

您是否需要任何其他信息进行调试？

请为我的问题提供解决方案。

您好、

Unknown 说：

来自 Serial_flash_programmer 的所有命令都完成后、应用程序代码无法运行。 仅在我切换到获取模式并复位 MCU 时有效。

在 serial_flash_programmer 中执行"1-DFU"后、您是否执行"6-Run"并指定了应用程序的入口点？

此致、
马特

您好、Matt、

是、我使用 run 命令并指定入口点  

我已经提到了我在上述讨论中执行的步骤。 您能否回顾完整的对话并相应地解决我的问题？

如果您需要任何具体细节、请告诉我。

Unknown 说：

9.应用程序代码被转储并要求 执行下一步、我选择选项6运行。

Unknown 说：

10.然后请求要分支到的地址。
11.I 复制了上面的入口点地址并粘贴在下面。

Rajamurugan,

收到运行命令后、器件分支到什么地址？ 这仅在从内核分支到应用程序时发生、还是在从闪存引导时发生？ 您能否使用 C2000闪存实用程序"Verify Only"函数根据.out 文件验证闪存的内容？

此致、

Alex

尊敬的 Matt：

下面、我已经解释了我的问题以供您澄清。

设置： 最初、我在调试模式下使用片上闪存工具更改了引导模式选择引脚、以便我们可以将默认 SCI 引脚用于引导加载程序。

问题： 完成引导加载程序过程后、 帧 命令成功执行、但应用程序代码未运行(它不会从内核转换到应用程序代码)。

Unknown 说：

收到运行命令后、器件分支到什么地址？

对于设置了 FLASHA 的代码、入口点地址为0x82c9a  

对于设置了 FLASHB 的代码、入口点地址为0x82d21  

Unknown 说：

仅在从内核分支到应用程序时还是从闪存引导时才会发生这种情况？

仅当从内核分支到应用程序时才会发生此问题。

从闪存引导时运行正常。

Unknown 说：

您可以使用 C2000闪存实用程序"Verify Only"函数根据.out 文件验证闪存的内容吗？

我可以确认在复位后从闪存引导时代码按预期工作。

您能否提供使用 C2000闪存实用程序通过.out 文件进行验证的步骤？

还有什么我需要澄清的吗？ 请在一个回复中编译所有必要的详细信息、以便我可以在一天内处理这些信息、并更快地回复您。

感谢您的帮助。 我期待着你的回应。

尊敬的 Rajamurugan：

Unknown 说：

从闪存启动时运行良好。

请指定地址 0x80000 在命令内核执行6-Run 时。 通常、您需要分支到应用程序的 codestart、这就是引导至闪存正常工作而串行闪存编程器则不能正常工作的原因。

Unknown 说：

请提供使用 C2000闪存实用程序来验证.out 文件的步骤吗？

在片上闪存工具(可在 CCS 中的 Tools > On-Chip Flash when connected to CPU1中找到)中、您可以将闪存实用程序指定为"Verify Only"(仅验证)、而不是在加载.out 文件时指定为"Erase and Program"(擦除和编程)。 然后、您可以通过加载应用程序的.out 来验证闪存的内容、并确认内核已成功对闪存进行编程。

此致、

马特

尊敬的 Matt：

Unknown 说：

请指定地址 0x80000 当您命令内核执行6次运行时。

我尝试使用此地址、但它没有分支到闪存、

BEGIN           	: origin = 0x080000, length = 0x000002
 
.cinit              : > FLASHA      PAGE = 0, ALIGN(8)
.pinit              : > FLASHA,     PAGE = 0, ALIGN(8)
.text               : >> FLASHB | FLASHC | FLASHD | FLASHE      PAGE = 0, ALIGN(8)
codestart           : > BEGIN       PAGE = 0, ALIGN(8)
   
   
.econst             : >> FLASHF | FLASHG | FLASHH      PAGE = 0, ALIGN(8)
.switch             : > FLASHA      PAGE = 0, ALIGN(8)

我还尝试使用  0x080000 代码中提到 codestart、但也无法按预期工作。

Unknown 说：

在片上闪存工具(在 CCS 中的 Tools > On-Chip Flash when connected to CPU1中找到)中、您可以在加载.out 文件时将闪存实用程序指定为"Verify Only"(仅验证)、而不是"Erase and Program"。 然后、您可以通过加载应用程序的.out 来验证闪存的内容、并确认内核已成功对闪存进行编程。

执行上述步骤后、我得到了以下提到的输出。

C28xx_CPU1: GEL Output: 
Memory Map Initialization Complete
C28xx_CPU1: Verification-Only step was successful.

因此、根据我的理解、代码是闪存、与应用代码的.out 文件相同  

并且使用 CODESSTART 地址作为入口点地址不起作用(引导加载程序运行后仍然无法加载应用程序)

Unknown 说：

一般来说、您需要分支到应用程序的 codestart、这就是为什么引导至闪存可以正常工作、而串行闪存编程器则无法正常工作的原因。

因此、完成 DFU 过程后的输出地址与 CODESTART 不同。

即使这个语句是正确的、它仍然没有分支到应用程序代码。 导致该问题的实际原因是什么。

请为此问题提供解决方案。

Rajamurugan,

从主机发出运行命令后是否可以暂停 CPU？ 它的执行地址是从哪个地址开始的？

此致、

Alex

您好 Alex、

Rajamurugan,

从主机发出运行命令后是否可以暂停 CPU？ 它的执行地址是从哪个地址开始的？

此致、

Alex

我目前正在我这边进行这方面的工作。

主要问题：-在 sci 引导加载程序进程之后控制器没有分支到应用程序代码。

同时、能否请您在结束时尝试模拟该问题？
如果可能、如果您能执行所有迭代并提供解决方案、我将不胜感激。 测试需要大量时间、后续步骤取决于您。

以下是我已经完成的迭代、结果显示在上述聊天中。

1. 闪存引导(0x0B)入口点地址设置为0x80000。 我已根据需要将申请放在该地址。

2. 修改了链接器命令文件、将应用程序代码存储在闪存 A 而不是闪存 B 中

3. 将 codestart (begin)地址更新为0x80000。

4. 已验证生成的.map文件—发现正确。

5. 在串行闪存编程器中执行"1-DFU"、然后执行"6-Run"以指定应用程序的入口点(0x80000)。 (前面已经提到过、此操作已完成。)

6. 仅当从内核分支到应用程序时、而不是直接从闪存引导时、才会发生该问题。

7. .out使用 C2000闪存实用程序的"Verify Only"(仅验证)功能验证文件中的闪存内容—验证成功通过。

8. 从内核执行"6-Run"时指定的地址0x80000—已测试、但不工作。

9. 应用程序的 codestart 的分支也经过测试—仍然无法正常工作。

如果您能够模拟问题并帮助确定解决方案、请告诉我。

非常感谢您的支持！