[参考译文] TMS320F28388D：引导加载程序设计

由于5月31日是 TI 假日、因此我们的回复可能会有一些延迟

您好、Stevin、

关于您的第一个问题-

CPU1内核可写入闪存、闪存 API 需要复制到 RAM。 有关如何将 F2838x 的闪存 API 复制到 RAM 的示例、请参阅 C2000Ware_3_04_00_00\driverlib\f2838x\examples\c28x\flashapi_ex1_programming 中的链接器命令文件。 有关如何将闪存内核写入闪存的示例、请参阅 F28004x SCI 闪存内核示例、并查看 f28004x_flash_Bank0_NoLDFU_lnk.cmd 或 f28004x_flash_Bank1_NoLDFU_lnk.cmd 文件。

为了将 CPU2或 CM 内核写入闪存、 需要修改工程的链接器命令文件、以便将工程放置在闪存中-对于这些工程、闪存 API 仍需要位于 RAM 中- CPU1用于引导 CPU2和 CM 的引导模式需要更改 以便 CPU2和 CM 将从闪存引导。  

关于您的第二个问题-

可以组合 CPU1 CCS 工程以允许在同一工程中启动 CPU2和 CM。 您需要确保在引导 CPU2或 CM 时、CPU1能够获得控制权、以便它也可以引导另一个内核。 目前，当 CPU1引导另一个内核时，它会等待另一个内核完成执行，然后跳转到闪存中应用程序的入口地址或触发看门狗复位 。 请确保您还具有足够的 CPU1项目内存、以便能够引导 CPU2和 CM。  

您可以参阅 C2000Ware_3_04_00_00\driverlib\f2838x\examples\c28x\boot 以获取有关如何在同一项目中引导 CPU2和 CM 的示例。  

还需要修改主机侧编程器、以便一次性对 CPU1、CPU2和 CM 进行编程。 目前、主机侧编程器允许 CPU1命令后跟 CPU2命令、或 CPU1命令后跟 CM 命令。 您需要修改主机端编程器的源代码、以允许编程器在所有3个内核之间切换。 如果您需要访问主机端编程器的源代码、我们可以离线开始讨论。  

谢谢、  

Anu

HY Anu、

 我们更改了链接器文件，给定了将 flashapis 加载到 RAM 的 RAM 函数。 这在 CPU!-CPU2 SCI 内核中有效，但在 μ CPU1­ CM SCI 内核中不起作用。

在此 CPU1-CM SCI 内核(闪存构建)中，DFU1 (即 CPU 1应用程序)更新工作正常，而不会加载内核。但是，当我们尝试通过 IPC 将 CM 内核加载到 CM RAM 时，加载过程每次都在条目地址操作码之后卡住。 我将附加链接器文件以及 Windows cmd 窗口的屏幕截图。 基于 IPC 的内核加载被卡住。新的基于闪存的链接器文件是根据同一项目的基于 RAM 的链接器文件生成的，msg_ram 部分已全部处理。

对内核所做的唯一更改是创建一个基于闪存的链接器文件、并包含

memcpy (&RamfuncsRunStart、&RamfuncsLoadStart、(size_t)&RamfuncsLoadSize)；

从 RAM 运行闪存 API。

我的主要原因是，与 Windows cmd 一样，我们能够看到密钥检查以及读取和丢弃16字节数据，基于 IPC 的内核加载不能按预期正常工作。

 e2e.ti.com/.../2838x_5F00_FLASH_5F00_lnk_5F00_cpu1.zip

谢谢、此致、

步进

Stevin、  

CPU1通常将 CPU2和 CM 内核写入 RAM。  

CPU1内核当前将 CPU2内核写入全局共享 RAM、然后引导 CPU2。 当 CPU2完成其引导过程时、它会将放置在 CPU1中的分支函数复制到 CPU2消息 RAM 中、并将其复制到 M1RAM 中、然后从 M1RAM 开始执行。 分支函数将其带到 CPU2内核的入口点。 仅修改 CPU2内核链接器命令文件并不能确保内核实际写入闪存、因为写入 CPU2内核的函数会写入 RAM。  

对于 CM 内核、 CPU1侧有一个复制函数、用于与 CM 侧的复制函数通信以传输内核- CPU1将块写入消息 RAM 中的缓冲区、并发送需要写入缓冲区内容的地址、 CM 获取缓冲区并将其写入 CPU1传递的地址。 需要修改 CM 侧的复制函数以写入闪存而不是 RAM。 话虽如此、如果要写入闪存、则无需使用此复制函数、只需使用 CCS 将 CM 内核下载到闪存、就像对 CPU1所做的那样。  

如果要将 CPU2和 CM 内核加载到闪存中、除了更改 CPU2和 CM 工程的链接器命令文件外、还需要更改 CPU1为 CPU2和 CM 设置的引导模式。 在闪存内核示例中、CPU2和 CM 的引导模式为"IPC 消息 RAM 复制和引导至 M1RAM"和"IPC 消息 RAM 复制和引导至 S0RAM"。 您需要将它们更改为其中一种闪存引导模式、具体取决于您将内核放置在闪存中的位置。 然后、您可以像对 CPU1那样将内核项目加载到 CPU2和 CM 的 CCS 中。

您可能还需要将 CPU2或 CM 与 CPU1同步、以便内核在 CPU1指示其执行之前不会执行。 您可以在 CPU2/CM 内核项目的主函数顶部以及 CPU1内核项目中设置 CPU2或 CM 的引导模式之后添加 IPC_SYNC()函数调用。  

此外、您需要修改主机端编程器、这样它就不会尝试通过 SCI 下载内核、因为内核是通过 CCS 编写的。 请联系您联系的 FAE、以便我们可以讨论如何向您发送主机编程器源文件。  

谢谢、  

Anu

HY Anu、

我已更改引导模式。 我目前正在尝试的是，在闪存中构建 CPU1 SCI 内核，并使用 serial_flash_programmer_apPLN_f2838x_cm.cmd 主机应用程序(它不会将 CPU1内核下载到 RAM 中)。

然后运行 DFU1 ，该器件将更新内核占用的闪存扇区中的应用程序(在 CPU1中)，再次使用 run_CPU1_boot_CM 选项，该选项将按照设计将 CM 内核下载到 CM RAM 中。 告知现在其 CPU1 SCI 内核只驻留在闪存中、而不是 CM SCI 内核中。 为此，我认为在 CPU1中只需要修改链接器文件。 更改链接器文件后，DFU1使用 serial_flash_programmer_APPLN_f2838x_cm.cmd 可以正常工作，并且也会在 CPU1中运行应用程序。 但是、当我尝试使用  run_CPU1_boot_CM 选项并下载 CM 内核时、代码会像您在上面的屏幕截图中看到的那样卡住。 CM 的 msg RAM 在闪存链接器文件中构建、正如 RAM 链接器文件中给出的那样。  为了避免这种情况、我应该怎么做？

谢谢、此致、

步进。

Stevin、  

感谢您的澄清。 如果您尝试将内核下载到 CM RAM、则可以在工程中使用原始引导模式。  

我尝试使用链接器 cmd 文件运行 F2838x CPU1内核工程、但无法重现您曾经遇到的错误。 您在项目中的这条线是在哪里？  

您是否在项目中添加了除该行以外的任何内容？ 此外、您是否为闪存添加了构建配置并在预定义符号中添加了"_flash"？  

谢谢、  

Anu

Anu、

我只在 main()函数的开头使用了 memcpy()。 我尚未添加闪存的构建配置、已将_FLASH 用作预定义符号。

1.在哪里可以使用链接器文件成功引导 CM 内核？

2.当我构建一个新的配置构建到闪存时，只需要正确定义宏_FLASH？

我还要补充一点、

我还尝试使用 RAM 构建内核将内核放入闪存中。 在这里，我将闪存构建 SCI 内核作为应用文件提供给在 RAM 中运行的 SCI 内核，当我们需要将 sci 内核放入闪存时，可以使用 它，而不受 CCS 的影响。 这适用于 CPU1 sci 内核以及 CPU2 sci 内核。 但是、当我尝试在中间执行 CPU1_CM 串行内核时、我会得到 "program_error"。为什么会这样？

谢谢、此致、

步骤

Anu、

我能够创建单独的闪存构建配置、方法是：_FLASH 并提供链接器文件。 我从调试窗口了解了代码的滞留位置。我将共享调试窗口的 ss，程序流停留在 while 循环中的绿色阴影部分。 请看一下。

在要从闪存加载到 RAM 的函数上方、我应该使用哪个 pragma？ 我应该为它提供哪些功能？

谢谢、此致、

步骤

Stevin、  

我能够使用 CPU1闪存构建 SCI 内核加载 CM 内核。

我需要确认一点-闪存中 CPU1的内核和应用程序是否映射到不同的扇区？ 这是我第一次使用链接器命令文件时遇到的一个问题、将应用程序映射到内核的不同扇区解决了这个问题。

您在上面粘贴的屏幕截图表示 CPU1正在等待 CM 同步。 应该有一个与此功能同步的 CM 复制功能。 您是否在 CCS 中连接到 CM？ 否则、CPU1达到上述函数时、复制函数将不会位于 CM 中。 您需要在 CCS 中连接到 CM、并在将 CPU1内核加载到器件后单击"Run"。 然后、CM 将等待设置其引导模式、当在内核中使用"Run CPU1 Load CM"选项时、CPU1将执行此操作。  

关于闪存构建配置的问题、_FLASH 符号应该足以表示符号。 由于我们还使用闪存 API、因此需要在链接器命令文件中引用该 API。 请查看下一次答复中粘贴的链接器命令文件。 您无需在主函数的开头添加 memcpy 函数。 在闪存构建配置的项目设置中定义_FLASH 符号时、InitSysCtrl 函数应负责调用该函数。  

关于 pragma 语句、除了闪存 API 函数之外、您还需要从 RAM 中运行哪些函数？  

关于通过串行闪存编程器加载闪存构建内核、您是否正在将所有已初始化的段映射到链接器命令文件中的闪存？ 它们是否与128位边界对齐？ 您可以使用链接器命令文件中的 align (8)指令来实现该目的。  

以下是链接器命令文件：  

MEMORY
{
   /* BEGIN is used for the "boot to Flash" bootloader mode   */
   BEGIN            : origin = 0x080000, length = 0x000002
   BOOT_RSVD        : origin = 0x000002, length = 0x0001AF     /* Part of M0, BOOT rom will use this for stack */
   RAMM0            : origin = 0x0001B1, length = 0x00024F
   RAMM1            : origin = 0x000400, length = 0x0003F8     /* on-chip RAM block M1 */
//   RAMM1_RSVD       : origin = 0x0007F8, length = 0x000008     /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */
   RAMD0            : origin = 0x00C000, length = 0x000800
   RAMD1            : origin = 0x00C800, length = 0x000800
   RAMLS0           : origin = 0x008000, length = 0x000800
   RAMLS1           : origin = 0x008800, length = 0x000800
   RAMLS2           : origin = 0x009000, length = 0x000800
   RAMLS3           : origin = 0x009800, length = 0x000800
   RAMLS4           : origin = 0x00A000, length = 0x000800
   RAMLS5           : origin = 0x00A800, length = 0x000800
   RAMLS6           : origin = 0x00B000, length = 0x000800
   RAMLS7           : origin = 0x00B800, length = 0x000800
   RAMGS0           : origin = 0x00D000, length = 0x001000

   RAMGS1           : origin = 0x00E000, length = 0x001000

   RAMGS2           : origin = 0x00F000, length = 0x001000
   RAMGS3           : origin = 0x010000, length = 0x001000
   RAMGS4           : origin = 0x011000, length = 0x001000
   RAMGS5           : origin = 0x012000, length = 0x001000
   RAMGS6           : origin = 0x013000, length = 0x001000
   RAMGS7           : origin = 0x014000, length = 0x001000
   RAMGS8           : origin = 0x015000, length = 0x001000
   RAMGS9           : origin = 0x016000, length = 0x001000
   RAMGS10          : origin = 0x017000, length = 0x001000
   RAMGS11          : origin = 0x018000, length = 0x001000
   RAMGS12          : origin = 0x019000, length = 0x001000
   RAMGS13          : origin = 0x01A000, length = 0x001000
   RAMGS14          : origin = 0x01B000, length = 0x001000
   RAMGS15          : origin = 0x01C000, length = 0x000FF8
//   RAMGS15_RSVD     : origin = 0x01CFF8, length = 0x000008     /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */

   /* Flash sectors */
   FLASH0           : origin = 0x080002, length = 0x001FFE  /* on-chip Flash */
   FLASH1           : origin = 0x082000, length = 0x002000  /* on-chip Flash */
   FLASH2           : origin = 0x084000, length = 0x002000  /* on-chip Flash */
   FLASH3           : origin = 0x086000, length = 0x002000  /* on-chip Flash */
   FLASH4           : origin = 0x088000, length = 0x008000  /* on-chip Flash */
   FLASH5           : origin = 0x090000, length = 0x008000  /* on-chip Flash */
   FLASH6           : origin = 0x098000, length = 0x008000  /* on-chip Flash */
   FLASH7           : origin = 0x0A0000, length = 0x008000  /* on-chip Flash */
   FLASH8           : origin = 0x0A8000, length = 0x008000  /* on-chip Flash */
   FLASH9           : origin = 0x0B0000, length = 0x008000  /* on-chip Flash */
   FLASH10          : origin = 0x0B8000, length = 0x002000  /* on-chip Flash */
   FLASH11          : origin = 0x0BA000, length = 0x002000  /* on-chip Flash */
   FLASH12          : origin = 0x0BC000, length = 0x002000  /* on-chip Flash */
   FLASH13          : origin = 0x0BE000, length = 0x001FF0  /* on-chip Flash */
//   FLASH13_RSVD     : origin = 0x0BFFF0, length = 0x000010  /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */

   CPU1TOCPU2RAM   : origin = 0x03A000, length = 0x000800
   CPU2TOCPU1RAM   : origin = 0x03B000, length = 0x000800

 // CPUTOCMRAM      : origin = 0x039000, length = 0x000800

   CPUTOCMRAM_0     : origin = 0x039000, length = 0x000400
   CPUTOCMRAM_1     : origin = 0x039400, length = 0x000400
   CMTOCPURAM       : origin = 0x038000, length = 0x000800

   CANA_MSG_RAM     : origin = 0x049000, length = 0x000800
   CANB_MSG_RAM     : origin = 0x04B000, length = 0x000800

   RESET            : origin = 0x3FFFC0, length = 0x000002
}

SECTIONS
{
   codestart           : >BEGIN, ALIGN(8)
   .text               : >> FLASH1 | FLASH2 | FLASH3 | FLASH4, ALIGN(8)
   .cinit              : > FLASH1, ALIGN(8)
   .switch             : > FLASH2, ALIGN(8)
   .reset              : > RESET, TYPE = DSECT /* not used, */
   .stack              : > RAMM1

#if defined(__TI_EABI__)
   .init_array      : > FLASH3, ALIGN(8)
   .bss             : > RAMLS5
   .bss:output      : > RAMLS3
   .bss:cio         : > RAMLS5
   .data            : > RAMLS5
   .sysmem          : > RAMLS5
   /* Initalized sections go in Flash */
   .const           : > FLASH2, ALIGN(8)
#else
   .pinit           : > FLASH4, ALIGN(8)
   .ebss            : > RAMLS5
   .esysmem         : > RAMLS5
   .cio             : > RAMLS5
   /* Initalized sections go in Flash */
   .econst          : >> FLASH3 | FLASH4, ALIGN(8)
#endif

   ramgs0 : > RAMGS0, type=NOINIT
   ramgs1 : > RAMGS1, type=NOINIT
   
   MSGRAM_CPU1_TO_CPU2 : > CPU1TOCPU2RAM, type=NOINIT
   MSGRAM_CPU2_TO_CPU1 : > CPU2TOCPU1RAM, type=NOINIT

   MSGRAM_CPU_TO_CM  : > CPUTOCMRAM_0, type=NOINIT
   MSGRAM_CPU_TO_CM_COPY_TO_S0_RAM : > CPUTOCMRAM_1, type=NOINIT
   MSGRAM_CM_TO_CPU    : > CMTOCPURAM, type=NOINIT

   /* The following section definition are for SDFM examples */

   Filter1_RegsFile : > RAMGS10,	 fill=0x1111
   Filter2_RegsFile : > RAMGS11,	 fill=0x2222
   Filter3_RegsFile : > RAMGS12,	 fill=0x3333
   Filter4_RegsFile : > RAMGS13,     fill=0x4444
   Difference_RegsFile : >RAMGS14, 	 fill=0x3333


/*   Filter_RegsFile  : > RAMGS0
   Filter1_RegsFile : > RAMGS1, fill=0x1111
   Filter2_RegsFile : > RAMGS2, fill=0x2222
   Filter3_RegsFile : > RAMGS3, fill=0x3333
   Filter4_RegsFile : > RAMGS4, fill=0x4444
   Difference_RegsFile : >RAMGS5, fill=0x3333
   */

    GROUP
   {
	   .TI.ramfunc
	   { -l F2838x_C28x_FlashAPI_COFF_18.12.0.LTS.lib}

   } LOAD = FLASH1 | FLASH2 | FLASH3 | FLASH4,
     RUN =  RAMGS5 | RAMGS6 | RAMGS7 |RAMGS8,
	 LOAD_START(_RamfuncsLoadStart),
	 LOAD_SIZE(_RamfuncsLoadSize),
	 LOAD_END(_RamfuncsLoadEnd),
	 RUN_START(_RamfuncsRunStart),
	 RUN_SIZE(_RamfuncsRunSize),
	 RUN_END(_RamfuncsRunEnd),
	 ALIGN(8)

}

Anu、

感谢您使用链接器 cmd。 但我遇到了错误  

"./2838x_flash_lnk_.cmd"、第128行：错误#10008-D：找不到文件"F2838x_C28x_FlashAPI_COFF_18.12.0.LTS.lib"
错误#10010：链接期间遇到错误；未生成"F2838x_sci_flash_kernel_C28x_cm_CPU1.out"

但我可以在 项目中看到 COFF 闪存 API 库文件。  

谢谢、此致、

步进
 

Stevin、  

在项目设置中、转到 C2000链接器>文件搜索路径、并在"Add"下添加$｛workspace_loc：/$｛ProjName｝｝

谢谢、  

Anu

HY Anu、

我仍会卡在同一个 while 循环中。 我已连接并运行 CM。 复制函数之间不会进行 IPC 同步。  当您尝试加载 cm 时、您在项目或代码中是否进行了任何其他更改？

如何构建 CM 内核8位流？二进制文本文件是否导致了问题。 您可以共享 CM 内核 txt 文件  

谢谢、此致、

步进

Stevin、  

我在加载 CM 内核时没有进行任何其他更改。 连接到 CPU1和 CM 时、您是否遵循自述文件中的步骤？ 首先需要连接到 CPU1、然后再连接到 CM。

如果您单击"Pause for CM"、显示的地址是什么？ 当 CM 在 CPU1上等待设置引导模式时、它应在地址范围0x180C - 0x1818中。 您可以参阅 F2838x TRM 中的表5-30来查看 CM 可以在中等待的引导段。 当 CPU1在复制函数中时、CM 应位于 S0RAM 中、在0x20000800范围内的某个位置。  

若要按照内核所需的格式设置 txt 文件的格式、可以使用以下编译后处理步骤：  

"$｛CG_TOOL_HEX｝""$｛BuildArtiftFileName｝"-boot -GPIO8 -a -o "$｛BuildArtiftFileBaseName｝.txt"

使用此命令创建了 CM 内核 txt 文件。  

谢谢、  

Anu

HY Anu、

我连接的是 ss、其中一个在引导前、另一个在引导 cm 后。 您可以看到、PC 在引导后也不指向 S0RAM。

这位于 DFU1之后，即 CM 启动之前

这个是 CM 引导执行后的情况

CM 下没有符号

谢谢、此致、

步进

Stevin、  

感谢您发布屏幕截图。 在 DFU1之后 CM 所处的地址告诉我 CM 不在引导代码中的正确段等待。 请按照自述文件中列出的步骤连接到 CPU1和 CM。 具体而言、以下是您需要遵循的步骤：  

1.连接到 CPU1

2.连接至 CM

3.单击 CPU1的"Reset"(重置)- CM 将设置为等待引导

4.单击 CM 的"Resume"(恢复)-它应该在正确的位置等待

5.将内核加载到 CPU1中并单击"Resume"

此时、您可以使用串行闪存编程器并下载 CM 内核。  

谢谢、  

Anu

HY Anu、

我尝试了自述文件说明，一次它工作正常，并完全下载了 CM 内核，但在该问题之后，再次出现了以前的卡死问题。  

仍然存在的困惑是、如果我们在不使用 CCS 的情况下启动、CM 应处于等待启动状态、 CPU1和 cm 中的复制 fn 应同步。 为什么不发生这种情况..

您使用的是闪存或 SCI 引导、哪种引导引脚模式

此致、

步进

Stevin、  

将 CCS 与 CM 内核配合使用时、为了避免卡住、需要确保 CM 在 CPU1设置 CM 的引导模式之前在正确的等待引导循环中等待。  

当不使用 CCS 时、我在引导引脚模式下使用了 SCI 引导、serial_flash_programr_f2838x_cm.exe、CPU1和 CM 复制功能能够正确同步。 我将研究闪存启动问题、请给我几天时间、以便与您联系。 同时、您可以尝试使用 SCI 引导吗？ 请注意、需要将 CPU1 RAM 构建配置用于 SCI 引导。  

谢谢、  

Anu

Anu、

感谢您的所有支持！！！！SCI 引导工作正常、没有问题。我现在将使用 SCI 引导、请告诉我问题何时得到解决。 用于闪存 SCI 引导加载程序。

在 SCI 引导模式(等待引导) 中，引导 ROM 等待一个密钥，只有当密钥错误时才会跳转到闪存。 如果需要使用 sci boot、这意味着每次复位时、我们都需要提供错误的密钥才能引导至闪存。  Soln 是否适用于这种情况？

最后， 是否可以使用 etherCAT 作为引导加载的外围设备，因为我看到 etherCAT 已连接到所有3个内核，是否可以使用它更新应用程序？

谢谢、此致、

步进

Stevin、  

有关如何切换引导模式的信息、请参阅 F2838x TRM 的引导一章。  

没有可用的 EtherCAT 引导加载程序、您可以创建自定义引导加载程序并将其编程到闪存或 RAM 中、然后使用它来执行应用更新。  

谢谢、  

Anu

Anu、

我有串行闪存编程器的项目文件，其中对于 run_CPU1_boot_CPU2情况(我已将其存储在闪存 中，因此无需加载) ，我注了停止内核下载并使用直接 DFU2所需的内核下载。 尽管内核下载已注释为“未发生”。 请指导我进行哪些更改  

我的目标是：由于我已将 CPU2内核存储在 CPU2的闪存中、因此在提供 run_CPU1_boot_CPU2选项时、我需要停止 CPU2的内核下载。

谢谢、此致、

步骤

Stevin、  

CPU2内核下载的函数调用应在 serial_flash_programmer 文件以及 CPU1的 CCS 工程中注释掉。 函数 SCI_Load_CPU2从主机查找要写入 RAM 的内核。 注释掉这一点将跳过目标端的此步骤。  

谢谢、  

Anu  

HY Anu、

我已经完成了此操作，完成上述步骤后，内核下载会跳过，但 DFU2会卡住，无法下载。  

此致、

步骤

Stevin、  

也许我们可以召开一次会议来进一步讨论。 请联系您的 FAE、我们可以安排会议。  

谢谢、

Anu

Anu、

期待您重放我们在会议期间讨论的问题

此致、

步进

Stevin、  

有几个不同的选项：

1. 首次对电路板进行编程时、您可以将引导引脚设置为 SCI 引导、并使用 RAM 中的 SCI 闪存内核将应用程序和内核写入闪存。 应用程序可以位于闪存的前几个扇区、接下来的几个扇区可以专用于闪存内核。 之后、您可以将引导引脚设置为闪存引导并保持原样、应用程序可以在需要升级固件时向内核发送信号。 鉴于讨论情况，这似乎不是你要做的，但为了完整起见，我在这里提到这一点。
2. 您可以将引导引脚设置为 SCI 引导并将其保持原样。 您可以将用户 OTP 配置为向引导表添加两种引导模式–SCI 引导和闪存引导。 这还需要将 GPIO 配置为引导模式选择引脚，以便在引导模式之间切换–当设备在现场时，您需要能够访问该设备，以便切换该引脚。 有关如何设置引导表的信息、请参阅 TRM 的第5.4节。 这似乎是尝试的理想路线。  
3. 如果您有 GPIO 引脚可设置为引导模式选择引脚，但无法在字段中切换引脚， 您可以参阅应用手册 SPRACN1、了解如何切换引脚–如果电路板已经生产、这可能不可行、但从较高层次看、应用将在固件升级时将 GPIO 引脚驱动为高电平 进行了比较。 以下是应用手册的链接： https://www.ti.com/lit/an/spracn1/spracn1.pdf
4. 我与引导所有者一起检查、您可以使用 USB Boot、如果超时发生、它将回退到闪存引导。

谢谢、  

Anu

Anu、

USB 引导加载程序是否可用于 f2838x？

此致、

步进

Stevin、  

当前没有可用的 USB 引导加载程序。 您可以修改要通过 USB 使用的 SCI 内核。 F2837xD USB 内核可用作参考。  

上面提到的第二个选择是否不可行？

谢谢、  

Anu

Anu、

看起来还可以、但我将与我的团队核实、然后返回给您。

谢谢、此致、

步进

Stevin、  

当然、听起来不错。  

谢谢、  

Anu