Other Parts Discussed in Thread: AWR1642, UNIFLASH, IWR6843, AWR1843, IWR6843AOP
主题中讨论的其他器件：AWR1642、 UNIFLASH、 IWR6843、 AWR1843、 IWR6843AOP
大家好、
我正在尝试通过 UART 将二进制映像加载到 AWR1642 RAM ( 引导加载程序流 SWRA551 应用手册中的 UART 引导模式路径、如下所示)。
我正在基于 Uniflash 生成的软件包中包含的工具运行 Python 脚本。 该脚本能够刷写图像(来自汽车工具箱的生命体征演示二进制文件)
使用 具有 meta_image1 (4)文件类型和 SFLASH (2)存储类型的向 SFLASH (0x24)命令写入文件到平台。
将 SOP 设置更改为功能模式后、应用程序正常启动并运行。
遗憾的是、当我尝试将映像加载到 RAM 时、应用程序看起来根本不运行。
根据应用手册： 通过 UART 进行的引导加载也遵循与之前提到的相同的顺序(写入命令–0x26)。 通过 UART 接收的元映像会被解释并加载到相应的存储器中。
引导加载完成后、会占用 ROM 并将执行控制传递到 MSS TCMA 中的应用程序。 元映像不应附加 CRC32 (与要刷写的映像不同)。
如果我理解正确、在使用写入文件到 RAM (0x26)并发送关闭命令通过 UART 加载映像后、它应将自身加载到 RAM 并开始执行(而不会将 SOP 配置从刷写更改为正常工作)。 应用程序会一直运行、直到器件复位。
当我使用具有 meta_image1 (4)文件类型和 SRAM (4)存储类型的写入文件到 RAM (0x26)命令发送相同的二进制文件(不带 CRC32)时、发送最后一个命令 关闭文件后不会发生任何情况。
上述加载和闪存编程之间存在一些差异：
-加载使用 写入文件到 RAM (0x26)命令；
－装载 SRAM 更改的存储类型(4)；
-文件映像的文件末尾不应包含 CRC32以供加载。
我不确定是否必须将文件拆分为 BSS 补丁和 MSS/DSS (补丁？) 如流程图中所示、或者它是否可以是一个图像元文件。 引导加载部分仅提到 元映像不应附加 CRC32 (与要刷写的映像不同) 、就好像映像之间的唯一区别是 EOF 上存在 CRC32一样。
在浏览各种文档时、我发现 AWR1642和 IWR6843之间存在一些差异、并且可能存在与引导加载程序版本相关的问题。
- AWR1642的"打开文件"命令仅具有文件类型、而 IWR6843具有存储类型和文件类型
- AWR1642的 Close file 命令具有文件类型、而 IWR6843具有存储类型
但是、加载不适用于任何这些命令集。
1.是否缺少任何步骤？ (如上所述-刷写工作正常)
2.加载的文件是否必须拆分为两个文件？
3.如何确保程序已启动并正在运行？ 是否有任何方法可以调试此行为？
期待您的回复。
谢谢、
Marcelina
