[参考译文] TM4C1294NCPDT：首次对定制板进行编程(tm4c1294ncpdt)

请允许我注意、对于(任何)"首次部署"的新电路板、  通过 "JTAG/SWD "进行"启动" 证明、 "非常喜欢！"

KISS 规定： "简单、有限、专注" 的第一步。   任何引导加载程序-根据定义-都是大规模违反！    请注意、对于(任何)"新电路板"-问题可能是"任何地方！"   因此、紧密聚焦、测量、亲吻的方法的价值！

希望 (正常/习惯)" JTAG/SWD 配置"包含在海报(定制)板上。   (因为这 始终证明是明智的/节省的)

与往常一样、应首先尝试使用最小/最简单的程序(即"闪烁")。    (并且-通过 JTAG/SWD)   

只有 在"JTAG/SWD 成功之后-应该  启动任何更雄心勃勃的"编程尝试"-

尊敬的先生，

[引用 user="Bob Crosby"]您是否正在使用25MHz 晶体？

               是的、我使用的是25MHz 晶体。

[引用 user="Bob Crosby"]如果在 RBIAS 和 GND 之间没有4.89K 的电阻器，则有时引导加载程序会被混淆。[/quot]

Rbais 和 GND 之间有4.7K 电阻器、可在 DMM 上提供4.529K 的值。

另一个问题是、我能否在根本不使用外部晶振的情况下(使用内部振荡器来减少错误可能性)启动负载？？  如果是、我必须在 boot_demo1和 boot_serial 示例中进行哪些更改或 在其他位置进行哪些更改？

此致、

Digvijay

你(们)好

有人可以帮我解决这个问题吗？

此致、

Digvijay

[引用 user="Digvijay khambe"]请有人能帮我解决这个问题吗？

先前提出的"这种帮助"(4月28日)是否导致(仅)沉默？    这对这里的其他人来说并不是特别令人鼓舞-并且(也许)解释您(正在进行中)的困境...

"您的道路"和"您的道路仅限"介绍了"许多"未知"、增加了极大的并发症！     一种简单得多的方法(更经典的使用方法和经验证的方法)仍然是“Cast Abide”——这是毫无道理的！   也许...  不是最好的方式——强迫志愿者帮助！

您好 CB1_MOBILE

     我已经在4月30日作了答复，之后又保持沉默。

    我从我知道的方法开始。 如果有更好、更简单的方法、我始终愿意这样做。  我没有关注 JTAG、因为现在我没有调试器、我完全不熟悉这个过程。

此致、

Digvijay

[报价用户="Digvijay khambe"]我完全不熟悉此过程
您是说您不熟悉 JTAG 还是一般不熟悉嵌入式开发？

我问的原因是、如果您不是新手、我会很好奇您的计划是什么。 您提到的这种方法是什么、您过去是否取得了成功？ 如果没有调试器、我无法进行开发。

我最初建议运行 dbgjtag 实用程序、但这需要 JTAG。 您的焊接技能是否熟练地将接头焊接到 JTAG 引脚？ 引脚很小。 如果没有显微镜、我就不会尝试这种方法。

也可以将 EK-XL Launch Pad 用作 JTAG、删除共享 GND 的0r 6、7、8、10、11、16、40、TP7。 然后 X11 (TXD/RXD)孔将线(X)交叉至定制 PCB UART (RXD/TXD)。 也可以通过带状电缆或跳线将 LaunchPad J6 JTAG 接头用于自定义 PCB JTAG 接头、而不是交叉线。 务必同意 CB1 100%、Blinky 可通过 PIOSC 或 MOSC 重写为使特定板 LED 闪烁、但需要一段时间才能弄清 Wacky ass GPIO 引脚移位仅适用于一个 LED。 现在、我的新款(Blinky.bin)运动款可翻转的 LED。 如果有人要求、我会将其发布在这里、让我知道 LED 将闪烁。

这比 XDS100更好、因为它为 LM 闪存和 CCS 调试检查创建了 CMD 虚拟链接、为调试列表创建了虚拟 COM 端口等。

尊敬的先生，

                   如 上所述、我尝试使用 JTAG 进行调试、但效果良好。 我能够下载 boot_demo1和 UART_echo 示例。 在 UART_echo 示例中、我能够使用终端和 uart0模块发送和接收数据。 因此、我可以得出结论、我的电力线、晶体、uart0部分工作正常。 但是、我仍然无法使用 UART 和 LM 闪存编程器下载 boot_demo1示例。 我已根据电路板更改了 boot_demo1示例中使用的引脚(switch 和 led)、这是唯一的更改。 但是、我仍然会得到与原始帖子相同的错误。 那么、在尝试下载 boot_demo1示例之前、我是否需要执行一些过程/步骤？？ 或者是否缺少其他东西？？

此致、

Digvijay

[引用 user="Bob Crosby"]您可能希望在 EK-TM4C1294XL 评估套件上使用未修改的示例尝试此序列。

对我来说，以上是一个很好的建议。   我未能检测到此海报"连接"到 UART 的"方式"-在他的"新/定制板"上。   这是(一些)重要的-是不是吗？

供应商套件使用 ICDI MCU 管理串行传输到 UART -尽管没有该套件-我处于(不太稳定)接地状态。   

在我看来、这种"连接方法"与各种 MCU UART 的连接方式始终具有改进的说明！   (即过于频繁... 甚至有一些解释。。。)

海报应指明他：  

• 串行信号源
• 所采用的信号电平(MCU 的 UART 限制为 CMOS/TTL 信号电平)
• 信号源与 MCU 的"受限"输入信号电平正确配合(按信号电平)的事实。

海报(刚才提到)通过 JTAG 取得了一些成功-这将会(更多)有帮助-更早到达。   它确实确定了(部分)板运行水平-总是很好！

e2e.ti.com/.../EK_5F00_TM4C1294XL.txte2e.ti.com/.../gpiointerrupt-_2800_2_2900_.txte2e.ti.com/.../gpiointerrupt.txtRespected先生，

        正如您所建议的、当我首先对 boot_serial 进行编程时、它会起作用。 但我仍然有一些疑问。

1.为什么不能使用 ROM 中的 boot_serial？ 当产品处于生产阶段时、JTAG 是不可行的选择。

2.我尝试将引导加载程序添加到 gpiointerrupt 示例中。 但我会遇到折页错误

已进入中断计数= 0

FSR = 0x0000

HFSR = 0x40000000

DFSR = 0x00000001

MMAR = 0xe000ed34

BFAR = 0xe000ed38

AFSR = 0x00000000

正在终止执行...

相关代码已随附。

此致

Digvijay

[引用 user="Digvijay khambe">1. 为什么无法使用 ROM 中的 boot_serial？？ 当产品处于生产阶段时、JTAG 是不可行的选项[/报价]

很好的一点 是、使用 JTAG、您可以批量擦除闪存并解决 ROM 引导加载程序故障的问题。 有关默认 POR 行为、请查看数据表中的 BOOTCFG 寄存器52。 BOOTCFG 文本位于多个部分中、使用 CTRL-F 搜索。  

注意到上面发布的 LM Flash 加载 偏移量0x4000、这是您的应用吗？ 串行引导加载程序必须加载到偏移量0x0、 然后 从0x4000 (应用)开始复制 到 SRAM 并从 SRAM 执行。  如果应用程序正在使用 DMA、非常大或具有 多个与存储器相关的函数、这可能会回退执行速度。   

关于您的第二个主题/问题、只有当您打算在初始生产编程后的某个时间升级固件时、将引导加载程序添加到 TI-RTOS 应用程序才有意义。 这是您真正的目标吗？ 如果是、您可以从 RTOS 调用 ROM 引导加载程序函数或调用自定义引导加载程序向量。 ROM 源代码可用。 您可以使用应用程序代码执行任何所需的操作！ 使用 添加到 RTOS 应用程序的引导加载程序(UART、USB、Ethenet 等)进行升级有许多选项。

我认为，这应该是它自己的职位。 您可能会分散对原始编程问题的帮助。

[引用 user="Peter Borenstein "]您可能会分散对原始编程问题的帮助。

说得好-朋友 Peter。   

尽管如此，我认为，并不局限于"仅此海报"，"过早地冲到启动加载机"(在最终应用程序"完全正确"测试/验证之前很长时间)，几乎可以保证项目将结束... 被遗弃了！    正如这张艰难的海报所承认的(他 长期以来一直"卡在这一步上"-没有那么大的成功)-继续前进的动力-只是 必须减少！

可能有人会问： “还有多少次尝试失败，使用引导加载程序-必须在这里着陆...  在"调用宰杀规则？   在 MCU 开发过程中、是否应(尝试)使用该器件(可能)"退回"？   这种"引导加载推回"方法 -至少-建立客户-用户的技能、体验和信心-在遇到并参与" 挑战！"之前

他/她 "率先上市"、(到目前为止)获得最高利润率吗？   然而-(勉强合理的) "推动启动" -魔鬼： "时间、能源、资金和士气！"  (在用尽“CrK Helper Crüe”时... (这很重要！)

引导加载程序通常是 在应用程序得到验证后部署的内容 、并且 (某些)市场潜力  得到确认。

减去这一点-正如海报 Peter  所指出的-过早急于"引导加载" 往往会导致"无法增强" 太多项目！   (如果他们到得太晚，土地就会很晚， 利润潜力 往往太多了。 有， 离开了大楼！)

尊敬的先生，

[引用 user="Peter Borenstein">关于您的第二个主题/问题、仅 当您打算在初始生产编程后的某个时间升级固件时、将引导加载程序添加到 TI-RTOS 应用程序才有意义。 这是您真正的目标吗？[/引述]

是的，我需要在初始生产编程后升级固件，例如，当产品在现场时。 这就是我不能使用 JTAG 的原因、我必须严格遵守 UART 串行编程。

[引用 user="Peter Borenstein"]如果是，可以从 RTOS 调用 ROM 引导加载程序函数或调用自定义引导加载程序向量。[/quot]

我尝试通过修改 gpiointerrupt 示例来调用引导加载程序。 但是、它通过给出上面的回复所示的消息来终止执行。 我在同一份回复中附上了经修改的代码。

此致、

Digvijay

尊敬的 CB1_MOBILE：

                         [引用 USER="CB1_MOBIT"]在最终应用程序"完全正确"测试/验证之前的如此长的时间内)[/quot]

 已在 TI-RTOS 中完成应用并使用 LaunchPad 进行验证。 因此只剩下引导加载部分

CB1_MOBILE 说：

您可能会分散对原始编程问题的帮助。

引导始终以使用 UART 串行在没有 JTAG 的情况下加载 TI-RTOS 应用为主要目标。 因此、我认为我没有偏离我的目标。

                          [引用 USER="CB1_MOBILE]]可以问， "还有多少次尝试失败，使用引导加载程序-必须在这里着陆...  在"调用宰杀规则？之前

我知道我正在努力推动。 我80%的工作已经完成、所以我现在不想放弃。 与我的问题相关的信息不在文档中。 所以、我必须向大家寻求帮助。

此致、

Digvijay

我5月5日的大部分(7：09/19：09)帖子是一个一般性的、"事实陈述"的帖子、只是部分针对您。   (但我认为仍然适用。)

通过使用论坛的搜索框(在本页顶部)、您只需注意大量的客户海报-与这些引导加载程序的斗争。   这意味着什么-是不是吗？

如果我们假设您有(部分)商业动机-这是否严重延迟-不会损害您的盈利？    在我公司的情况下-如果我们延迟这么久-'头会滚！'   您不太可能弥补这些财务损失！   

引导加载程序有一种替代方法、可以看到您将第二个设备发运给客户端、并在原始设备返回时计入该客户端。   这种方法并不少见、而且会为您的设计增加安全性。   (任何引导加载程序都可为您的代码提供(简化)"后门"条目)

这里没有人想看到你如此艰难-似乎(有些)不是"相当正确"-有这么多-就像你一样-在这一努力中挣扎...

尊敬的 CB1_MOBILE

 那么、是否有解决方案呢？  我真的需要它。

此致、

Digvijay

[引用 user="Digvijay khambe">在对 RTOS 应用程序进行编程时，我将在控制台中获取消息，如上述同一答复中所示。 那么、如何将引导加载程序添加到 TI-RTOS 应用程序？
[/报价]

对于 自定义 PCB UART0如何连接到 PC、您保持沉默、例如、Bob 或 CB1的同一问题没有发布原理图或答案。

问： 自定义 PCB UART0连接已(验证) 在 回波模式下使用虚拟 COM 端口将 TXD / RXD 数据连接到 Windows 控制台？

如果  未 配置进入窗口的自定义 PCB UART0路径(全双工)、ROM 引导加载 程序可能会失败！  

您知道 ROMBL 在出厂时嵌入到 MCU 中、因此您不需要刷写 串行 BL？

我们 主要需要验证 ROMBL 为何难以找到 COM 路径或在 POR 后使 MCU 停止/故障。 请详细说明定制 PCB 如何通过 CCS 调试查看 寄存器对 UART 连接做出反应、如下所述。  

必须将 CCS XML 文件配置为  在启动时不加载应用程序到调试中。  进入 CCS 调试后 、连续刷新并透视 UART0寄存器。 然后 、通过 CCS 调试中的虚拟 COM 端口建立到定制 PCB UART0的控制台连接。  您是否在 UART 寄存器或控制台窗口中看到任何活动？

*** 类似 ***   海报的(选择性)回答-增加他的延迟和沮丧...

非常好的细节-有一个(希望)会被赞赏。

[引用 user="Digvijay khambe">是否有解决方案？  我真的需要它。

这是一个命令-不是吗？    不是特别被承认为“向他人”——对你的帮助！    让您的沮丧情绪"溢流"给他人(为您投入时间/精力)表现出不成熟...   这里没有人——无论如何——都不会造成你的困境！

我最近的帖子-争辩说(很可能)供应商必须提供"更详细的信息"-因为许多(不仅仅是您)似乎受到 引导加载程序施加的(多)要求的"过度挑战"。   

至于解决方案-"在您能够"管理引导加载程序"之前-这是一种经过验证的替代方案-已经介绍！   (尽管您的沮丧之言-我/他人-希望您(最终)成功。)

[引用 user="Bob Crosby">可以使用基于 ROM 的引导加载程序对器件进行重新编程。 应用程序必须在调用基于 ROM 的引导加载程序之前禁用所有中断

  如果为了使 ROM 引导加载程序 能够在 地址0x4处看到0xFFFF.FFFF、闪存必须被擦除、这是怎么可能的？

 嵌入式 ROM-BL 是否具有类似 的闪存擦除 功能并且会清除 BOOTCFG 的 EN 位？

如果是、  这对于过去 通过   串行引导加载程序调用固件更新功能的现有应用而言是个好消息。

毫无疑问、这只是"美妙的细节"。    也就是说、在其他任何地方、这些信息是否标记良好、甚至突出显示？   清晰的长期海报/用户 BP101 -"没有这种知识！"

当然，“不是你的工作”——但这不是进一步的，而是“说明理由”“进一步解释细节”——比如 你刚才透露的那样？   

这么多的引导加载程序-与任何/所有的引导加载程序都有纠缠和挣扎-这一事实强烈地表明、"添加详细信息的严格要求！"   (除了通常至关重要的"刀头和刀头"(如您在上面的帖子)外、这将很快成为"旋转到论坛中！")   (并且只有很少(如果有) 再次 查看...)

我相信 Bob 所指的空白检查位于从 BL_STARTUP_CCS.s 调用的 BL_CHECK_c 中、该检查似乎在所有引导加载程序示例中：

uint32_t
CheckForceUpdate (void)
｛
#ifdef CHECK_CRC
uint32_t ui32Retcode；
#endif

#ifdef BL_check_update_fn_hook
//
//如果连接了更新检查函数，请调用应用程序来确定
//如何继续。
//
return (bl_check_update_fn_hook ())；
#else
uint32_t * pui32App；

#ifdef enable_update_check
G_ui32Forced = 0；
#endif

//
//查看第一个位置是0xffffffffff 还是不是这样的位置
//看起来像堆栈指针，或者第二个位置是0xffffffff 或
//看起来不像复位矢量的内容。
//
pui32App =(uint32_t *) app_start_address；
if ((pui32App[0]= 0xffffffff)||
((pui32App[0]& 0xFF00000)！= 0x20000000)||
(pui32App[1]=0xffffffff)||
((pui32App[1]和0xfff00001)！= 0x00000001))
｛
返回(1)；
} 

Bob、

谢谢-非常感谢。   作为一名(过去)技术作家(几个"帽子"中的一个)在另一个半"巨人"中-我意识到"文档是(从未)-真的完成了！"   但是、正如您和其他许多(供应商和客户端-用户)必须注意到的那样、 用户的比例"太高"- 在尝试使用 引导加载程序时失败(并且严重)。   很高兴知道 这种情况已被注意到-并且已"着陆"在(部分)列表上...

对 Peter 来说、您并不是真的期望每位客户-每位用户都使用"挖掘"每一个源文件-直到(可能)"发现"-非常需要的数据。

相反、我建议 引入更清晰、更详细的"引导加载程序说明"。    

这样 就避免 了——这是一种令人痛苦的模糊方法——你(以某种方式)似乎建议的方法！   (即使-尤其是-您注意到'(那个)代码-出现在所有引导加载程序表现中！')     这两份外部海报是否都没有错过？   (Thread Author & BP101)   这是100%  的错失率-是不是吗？    

您是否认为"没有这样的改进/扩展-描述性/引导-启动高级引导加载程序工作？"    真的吗？

我不想说来源是文件的替代。 我的目的是在小金额方面提供帮助并扩大我自己的理解。

我对文档有一些看法。 在这种情况下、TivaWare 引导加载程序指南(SPMU301D)的第9.11节介绍了 BL_CHECK_c。 缺点是知道 ROM_API 是否调用此函数。

请注意"我相信"这几个字。 这是一个猜测！ 通过指定用于使 ROM 功能的源代码项目、TI 将立即获得价值。 这将比全面的文件所需的时间更短。 正如您所说、很难进行梳理、但并非不可能。 有优点可供选择。

目前、有些问题只有在 TI 员工花时间回答时才能回答。 我不认为 BP101的问题可以在无限的时间内得到解答。 另一个相关的不可能的问题示例是： e2e.ti.com/.../301719

正如您在主题中所说的、"已验证"的答案在我看来只是"铅笔已验证"。

另一个问题是、文档分散。 答案来自源代码、CDOC、PDF 和 wiki。 勤奋的工程师必须梳理所有这些资源、才能达到请求帮助的目的。 这会导致完整性下降。 我应该花时间寻找可能不存在的答案、还是应该懒惰并发布新的主题？

为了给 TI 带来荣誉、我在发布的许多问题都可以通过打开 TivaWare 安装的文档/文件夹来得到解答。 我尊重所做的工作。

您不仅仅是在尊重所做的工作。   但是-即使是"工作完成"-正如这里每天都证明的那样-也可以改进！   (与故障数量成正比-引导加载程序确实值得(进一步)注意...)

[引用 user="Bob Crosby"]应用程序将配置 UART0，然后调用在 ROM.h[/quot]中声明的"ROM_UpdateUART()"。

因此，您的 ROMBL 会清除嵌入式函数"ROM_UpdateUART()"中的 BOOTCFG 寄存器 EN 位， 并且是  ROM.h 中的高级器件类调用

同样、Piccolo 利用 预写入的库类调用  来调用多个不同 MCU 中的嵌入式 Motorware 函数。 Motorware InstaSpin 函数 用于一  个及更高版本的 ROM 类调用、以调用 FOC 旋转算法、更具体地说、无需调用 InstaSpin 库。  首先很难掌握并非所有 F286x MCU 都具有嵌入 式 InstaSpin 类调用、而是利用 对 FOC 旋转算法的类调用 所有 F286x 据说都包含在内。    

ROM  嵌入式器件类调用也许是创建 简单 PDF 或(rombl.c) 以访问所有嵌入式函数的关键。  

感谢 Bob 所需的澄清！ )  

[引用 user="BP101"]这样，您的 ROMBL 会将嵌入式函数"ROM_UpdateUART()"[/quot]中的 BOOTCFG 寄存器 EN 位清零

不、我想说的是、有三种方法可以调用 ROM 引导加载程序。

如果闪存的前8个字节为空(0xFF)、ROM 引导加载程序将运行并循环检查不同的外设以连接到建立引导加载协议的器件。

2.如果引导配置非易失性寄存器被编程为选择 GPIO 引脚以激活引导加载程序、并且该 GPIO 引脚在复位释放时处于选定的状态、那么 ROM 引导加载程序将运行。

3.如果应用程序对 ROM 中的一个引导加载程序更新函数进行特定调用，例如"ROM_UpdateUART()"。 在这种情况下、必须在调用 ROM_Updatexxx 函数之前由应用程序初始化外设。

这是我在之前的帖子中提到的第三种方法。

[引用 user="Bob Crosby"]1. 如果闪存的前8个字节为空(0xFF)、ROM 引导加载程序将运行并循环检查不同的外设以连接到建立引导加载协议的器件。

奇怪的数据表 ROM 引导加载程序 BOOTCFG 寄存器文本指出它只检查位置(0x4)是否为0xFF。

[引用 user="Bob Crosby"]2. 如果引导配置非易失性寄存器被编程为选择一个 GPIO 引脚来激活引导加载程序、并且该 GPIO 引脚在复位释放时处于所选状态、那么 ROM 引导加载程序将运行。[/quot]

数据表中没有非常清楚 要设置的端口 H 引脚 绕过 通过 BOOTCFG 寄存器 EN 引脚进行的空白检查、好的是不需要闪存擦除。  

[引用 user="Bob Crosby"]3. 如果应用程序对 ROM 中的引导加载程序更新函数之一进行特定调用，例如"ROM_UpdateUART()"。 在这种情况下、外设必须在调用 ROM_Updatexxx 函数之前由应用程序初始化。

 昨天已测试此方法、调用 ROM_UpdateEMAC (120000000)。  通常、我们  通过 INT 0x02调用串行引导加载程序、以便从 TFTP 服务器将*。bin 上载到目标。   ROM_UPDATE EMAC ()的应用更新调用会关闭闪烁的 LED、 清除 NVIC 中断、禁用看门狗、然后在客户端发布消息 "找不到 BootP 服务器"时对 MCU 进行故障诊断。  EMAC0正由从   GUI 嵌入式 TFTP 服务器上载(*。bin)到目标的应用程序 telnet 端口使用。  不确定 MCU 出现了什么故障、但怀疑  目标 BOOTP 服务器包装程序的调用信号量被占用。

还测试了 ROM_UpdateUART()(TM4C1294KCPDT) ，但 通过  TM4C123 ICDI 将 UART3用于虚拟 COM，它 也使 MCU 发生故障。 甚至为虚拟 COM 端口设置了 LM 闪存 并 发布了类似消息。 也许稍后会再次测试这个、但是发现 Tivaware ROM  PDF 中缺少与 嵌入式函数执行步骤相关的任何细节。

想了一下 MUC 出现故障的原因；想知道 ROM 调用是否期望应用程序之前已刷写偏移量0x0？ 也许希望 UART/EMAC 矢量表位于 偏移量0x0000.4000的0x0之上、并在更新过程中覆盖当前矢量表配置？

如果 ROM 更新需要(0x0000.4000)偏移矢量表、这将是一个交易断路器。 在我看来、这与 ROM 嵌入式闪存实用程序的想法背道而驰、因此我们不必将应用程序偏移到0x0000.4000即可为串行引导存储器矢量表腾出空间。

尊敬的先生，

     [引用 user ="BP101"]您对 自定义 PCB UART0如何连接到 PC 保持沉默，例如，Bob 或 CB1的同一问题没有发布原理图或回答。

     我使用 的是用于常规通信的 UART 电路。 我已经测试了它的发送和接收操作。 我已使用 UART0引导加载了嵌入式固件。 因此 UART 电路不是问题。 TI-RTOS 应用程序有问题。 我无法从 TI-RTOS 应用程序调用更新(引导加载程序)函数。

尊敬的先生，

      感谢这样简单的解释。

    [引用 user="Bob Crosby"]

如果引导配置非易失性寄存器被编程为选择一个 GPIO 引脚来激活引导加载程序、并且该 GPIO 引脚在复位被释放时处于所选的状态、那么 ROM 引导加载程序将运行。

[/报价]

   正如您在第二个选项中建议的 、我尝试配置 GPIO 引脚以激活引导加载程序。 但我发现只能从特定端口选择 GPIO 引脚。 我选择的端口不是引导加载程序中指定的特定端口。 我保留了一些可用的 GPIO 引脚、但令我吃惊的是、这些引脚都是无用的。 因此、我无法实现此选项。 因此、我只剩下第三个选项。

[引用 user="Bob Crosby"]3. 如果应用程序对 ROM 中的引导加载程序更新函数之一进行特定调用，例如"ROM_UpdateUART()"。 在这种情况下、外设必须在调用 ROM_Updatexxx 函数之前由应用程序初始化

        从收集到的所有信息来看，我可以得出结论，要实现第三个选项，我必须在 TI-RTOS 应用程序中添加一些智能(如 GPIO 中断)，以调用函数  "ROM_UpdateUART()"。  调用此函数后、控制器将进入更新模式(希望没有任何故障)。 如果我错了、请纠正我的问题。

       BP101还提到、保留0x0000.4000作为偏移会导致故障条件。   那么 、我应该 保持0x0000.0000或0x0000.4000的偏移量是多少？

此致、

Digvijay

引用0x4000地址是因为芯片删除了16kB 扇区中的闪存。 数据表的第8.2.3.10节说明了这一点。 0x4000是0之后的第一个16kB 边界。 大多数引导加载程序将适合16kB、因此大多数具有基于闪存的引导加载程序的应用程序将启动第一个边界、而矢量表是第一个边界。 假设引导加载程序为17KB；您需要保留前2个16KB 扇区、因此您的应用程序将从地址0x8000开始。

处理器使用4字节字、因此您不能从奇数地址开始。 您可以从16kB 边界开始、但会浪费存储器。

此偏移量被基于闪存的引导加载程序用作 APP_START_ADDRESS (如我引用的代码中所示)。 我不清楚 ROM 引导加载程序使用什么作为 APP_START_ADDRESS、因此 BP101有问题。 我假设它期望矢量表为0。

我也愿意接受更正。

编辑：按矢量表、我是指中断和复位矢量表。 ROM 函数位于基于 ROM 的矢量表中。

尊敬的先生，

        感谢您的快速回复。  闪存引导加载程序将引导加载程序放置在0x0000.0000处、将应用程序放置在0x0000.4000处、但在 ROM 引导加载程序中、没有将引导加载程序放置在0x0000.0000处。 因此、如果我们将 APP 保持在0x0000.4000、则0x0000.0000和0x0000.4000之间的存储器为空。 我认为这就是它产生错误的原因。  我需要在实验室中检查它。 总之、我是否编写了更新 TI-RTOS 应用程序的步骤、偏移部件除外？？

此致、

Digvijay

您好、Digvijay、

这是我使用 ROM_EMAC (120000000)测试的第三个选项、应用偏移 量为0x0。    然后、MCU 故障后的目标发出消息"CAN not find BOOTP server"。 如果您也 收到 了同样的消息、请告知我们。 另一个调用 ROM_UART()仅支持 UART0 典型 RTOS 器    件，只需调用 Board_initUART()；，调用中断是加载记录器配置的一部分。  

此外 、还应使用 选项2 - GPIO 引脚 H3、因为它是  端口 H 上的最后一个引脚 、无论 BOOTCFG 寄存器  引脚7的默认值如何、它也是最后一个引脚。  具有8个引脚的 GPIO 必须用于另一个 MCU。

尊敬的先生，

         我尝试使用第三种方法加载引导、但它不起作用。 在中，调试器控制转到 ROM_UpdateUART()，但之后无法跟踪。 我认为我无法访问 ROM 函数。 我在 zip 文件中附加了代码、LM 闪存编程器配置和错误捕捉。

e2e.ti.com/.../5504.bootloader.zip

此致，

Digvijay