This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] UNIFLASH:UNIFLASH

Guru**** 2348500 points
Other Parts Discussed in Thread: UNIFLASH, IWR1843BOOST, IWR6843, IWR1843
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1103738/uniflash-uniflash

器件型号:UNIFLASH
主题中讨论的其他器件: IWR1843BOOSTIWR6843IWR1843

您好!

我是通过传感器论坛开始这一活动的、他们已经为我指明了方向...

我需要编写自己的工具来对 IWR1843BOOST 进行编程-如 UNIFLASH、但要将其集成到我自己的工具集中。

我有文档 SWRA627、我知道 flashPython 和 mmWaneProgFlash。 这些应该是我所需要的,但似乎并不是很好。

我自己的软件看起来与 mmWaveProgFlash 非常相似、所以我不能太远、但有些东西不正确。  如果我解压开箱即用演示并检查其是否正常工作,然后使用我自己的代码加载相同的.bin MSTR 格式文件,它将不再工作...所以我必须写入,但不正确。

我已附加一个文件、其中显示了我的一些工作方式:如何解析 bin 文件的头文件详细信息(来自工业工具箱、OOB 演示磁盘预构建)、 然后是我实际上发送到 IWR 的数据样本-部分完成、因此您可以让我 在末尾发送一个较小的余数(<240 bytes)数据包、加上关闭和打开命令以及下一个 metaImage 的开始。  显然出什么问题了吗? 注意:不发送 CR/LF 字节,<>仅在所示文本中显示,以使其清晰... 未发送到 COM 端口。

正如我所理解的那样-我需要了解的是、UNIFLASH 与 IWR 的对话应该在 python 中提供。  正如前面所说的、它看起来非常像我自己的代码(c#)、但我无法完全看到它是如何工作的。  有人建议、向 python 添加一些更多的文本输出将有所帮助-我已经在 send_packet 位中完成了这一操作(看起来是最低级别、被其他所有器件所使用)、但这只报告擦除函数、而不是传递数据。

我想我已经执行了 SWRA627协议、但显然还不是很好。  您能帮我找出我所附数据中的错误、还是帮助我了解 UNIFLASH 例程/获取更多文本、以便我可以观察它的功能。

特别是:

  • 由于我自己的代码非常相似、我必须靠近 open/cose 和 WritetoFlash (实际上想要使用 WritetoSRAM ..我的代码可以选择其中一个)。  我想我理解 Python 是如何实现这一目标的。
  • 我看不到 python 是如何从 bin 文件中挑选 metaImages 的。  我知道 uniflash 需要 MSTR 格式、但尚未找到/了解 python 中的该位。  如果写入代码正常、那么我的错误可能在这里吗?

非常感谢

Alan Milne、英国

e2e.ti.com/.../oobPreBuiltParseAndSend.txt

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Alan:

    我需要将此问题上报给 UniFlash 工程师。 我会随时向您发布我收到的任何更新消息。

    谢谢

    Ki

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我将提请器件专家注意此主题。 他们拥有有问题的 python 脚本、可以提供更好的帮助

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好 Ki、

    谢谢!  我正在设置 PC (和我的大脑!) python、我以前没有使用过它。  因此、我应该能够自己运行脚本-并添加更多文本输出、以便我可以看到正在发生的情况。  当然、python 上有一个水平、用于定义调用中的参数-希望我仍然可以解决它。

    Alan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Alan:

    我们的团队正在对此进行调查、并将在几天内回复您。 如果 EOD 5/31没有回答、请给我们打个电话。

    谢谢、

    Angie

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    需要补充一点、这可能有助于重点关注问题所在:

    我已经让 mmWaveProgFlash python 在 PC 上或多或少地自行运行、并添加了更多输出-有点像我附加的文件、但我无法使其非常好地进行格式化。  这当然有两个问题:

    • 提供有关 python 的专业知识(在零和不多之间)、我本来可以打破原始逻辑
    • 我没有上面的程序、它调用例程(例如、第590行中的 download_file)、因此我不知道 UNUFLASH 发送的参数

    但是,它似乎要做的(假设 image_creator MSTR 格式.bin 文件为输入)只是发送整个文件...未解析。

    当我读取 SWRA627时、这不是我要做的-我应该解析每个 meteImage、然后分别发送每个 meteImage。  但是、正如前面所说的、我没有实际的 UNIFLASH 调用 download_file、因此我可能只是给它提供了错误的文件来处理它。

    我认为有四种可能性:

    1. 我不理解 SWRA627如何设置每个元映像的格式
    2. 我不理解该文档如何拆分 MSTR 文件的元映像(您可能会在我的附件中看到这两个文件的内容)
    3. 由于我没有 python 上面的代码,也许我要求它处理错误的文件...这可能指向2)上面,即 UNIFLASH 解析元映像并为每个变量调用 down_load_file
    4. UNIFLASH 实际上正在发送整个 MSTR 格式文件。  这不是我认为 SRWA 所说的。  如果它正在发送整个 MSTR 文件、如何设置文件类型参数- open 命令所说的参数应该是四个 metaImages 中的一个(SWRA 表2)?

    希望这对您有所帮助!

    非常感谢

    Alan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Alan:

    您应该能够一次将整个图像分成较小的块发送出去。 已将纸槽格式化、以便正确放置在闪存中。 您在文档中的哪个位置看到它说它应该被分解成单个计量单位?

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Jackson、

    实际上、我开始想知道我是否能够弥补这一点!  但是(例如,我如何解释单词...可能是错误的):imageCreator 文档中的图2显示了四个 metaImages,用于 MSS/BSS/DS/Config -然后 SWRA627中的表2介绍了发送四个单独的 metaImages, open 命令也包括 metaImage ID。  我认为我所做的是解释为 MSTR 文件必须分开、而 metaImages 必须单独发送。

    以防万一-我已经修改了我的代码以将整个内容发送到一个片段中(作为240字节的块)。  这具有相同的结果、即它肯定是在编写、但还不正确。  让我们看看我是否可以粘贴此传输的开始和结束:

    2:{Open to SRAM}元映像编号:1元映像类型:4
    <00><13><76><21><00><04> <80><00><00><00><04><00><00><00><00><04><00><00><00><00><00><00><00>
    3:{Write to SRAM}metaImage 编号:1 metaImage 类型:4
    块:0 bin 文件 addr:00000000
    <00> <00><26>
    <4D><53><54><52><03><00><00><00>:<37><00><00><00> <9c><4c><19>
    <62> <9b> <80> <04><00>:<01><00><00><00><00><00><00><51><35>
    <80><00><00><00><43><2c><7a> :<22><4a><9f><06><78> <01><00>
    <00><00><00><00><00><00><00><00><00><00>:<01><00><00><00><00><00><00><00><00><51>
    <00> <01><00><98><7a><5d> : <98><1a><5c><40><88><00><00>
    <00><00><00><00><00><00><00><00><00><00>:<01><00><00><00><00><00><00><00><00><51>
    <40><74><02><00><41> <45> :<6c><89> <12><30><76><02><00>
    <00><00><00><00><00><00><00><00><00><00>:<08><00><00><00><00><4D><45><4e><44>
    <52><50><52><43><10><76><01><00>:<00><00><00><00><04><00><00><00><00>
    <01><00><00><00><00><00><00><00><00><00>:<00><00><00><00><00><00><00><00><00><00>
    3c><00><00><00><00><00><00><00><00><00>:<00><00><00><00><00><00><00><00><00><00>

    块:1342余数
    bin 文件 addr:0004EA20
    <00><63><09><26>
    <4e><7f><00><88><21><80><00>:<8e><21><80><00><88><21><80><00>
    <80><21><80><00> <21><80><00>: <21><80><00> <21><80><00>
    <21><80><00><00><00><00><00><00>: 81><00><00><00><00><00><00>
    0c><00><00><00><00><00><00><00><00><00>:<00><00><00><00><00><00><00><00><00><00>
    <00><00><00><00><00><00><00><00><00>:<00><00><00><00><00><00><00><00><00><00><00>
    <00><00><00><00><00><00><00><00><00>:<00><00><00><00><00><00><00><00><00><00><00>

    1346:{Close to SRAM}
    <00><07><04><22><00><00><00><00><04>

    请注意,我发送的是正确的余数,而不是整个块...也许我今天会尝试这种修改。

    您能看到我的格式/代码/CRC 等有什么问题吗?  这是一个 SRAM 加载-您可以看到闪存和 SRAM 之间的加载速度有明显差异、因此我必须将该位近似为正确位。  此外、我认为整个文件 CRC 是为闪存发送的、而不是为 SRAM 发送的?

    因此、请务必严格检查我要发送的内容:必须是相当简单的内容、因为它即将开始工作、我需要查看在下载期间添加状态请求、看看这是否告诉我任何信息。  那么、为了让我全面了解该协议、我要谈三点:

    1) 1)引导加载程序是否仅接受 MSTR 格式?  我还想知道是否可以单独发送 DSS (可能是 RPRC 格式)...已经加载了 MSS/BSS。  可以节省开发期间的下载时间。  但是,发送整个 MSTR 至少包括内存分配... SWRA 中没有单独介绍。

    在 UNIFLASH Python 中:

    2) 2)擦除命令似乎有一个存储类型的参数、该参数不在 SWRA627中。  这是否意味着我可以擦除 SRAM?

    3) 3) open 命令(实际上是_send_start_ddownload、第423行)有一个"mirror_enabled"参数。 这似乎进入了保留字节-我知道 SWRA 说将这些保留为零、但它会做什么?  我不认为它会使引导加载程序回显发送的内容、有机会吗?  这将是最有用的!

    第1)点对我如何执行开发周期有教育意义、第2)和第3)点对澄清有教育意义- python 和 SWRA 似乎不太同意、我想将准确正确的数据发送到引导加载程序。

    谢谢!

    Alan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    一些进展:我一直在使用对 SRAM 的写入(即避免使用 SFLASH 寿命) 、但如果我正确读取了状态信息、这(第12页的 SWRA 顶部)不会设置状态信息。

    更改为 SFLASH -在加载后询问状态、我获得最后一个数据的 ACK、但 在关闭时回复<00><04><33><00><33>。  SWRA 不会说这是什么...但是 python 确实是这样的...所以它看起来加载程序不喜欢 close 命令。 如下所示:

    发送:

    <63> <9f>
    1347:{getStatus}
    <00><03><23><23>
    1348:{Close to Flash}
    <00><07><04><22><00><00><00><00><04>
    1349:{getStatus}
    <00><03><23><23>

    接收:

    块:1342余数
    rxLength:5字节
    <00><04> <00>
    1347:{getStatus}rxLength:4字节
    <00><03><40><40>
    1348:{Close to Flash}rxLength:5字节
    <00><04><33><00><33>
    1349:{getStatus}rxLength:4字节
    <00><03><40><40>

    但是、最终状态似乎是"正常"。

    >>现在、查看 Close 命令- SWRA (图8)显示它包含存储类型、对于 SFLASH、该存储类型应该为2。  但是、python (第431行)发送 file_ID、对于 metaImage1、该值为4。 所以 python 和 doc 不同意。如果我理解吗?

    实际上,我已经尝试了这两种格式,都得到了一个否定应答...看起来我们已经接近问题了-下载正常,但关闭错误了? (我确实有错误、校验和错误、但我修复了该位、如上所示)。

    关闭命令中的问题吗?

    谢谢

    Alan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    为了简单起见、SWRA 确实有一些缩写信息。 如果有疑问、我会关注 python 代码中已实现的内容。 您是否看到 python 文件在发送 Close 命令时接收到什么?  

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Jackson、

    是的、使用 python 而不是 swra 似乎是合理的。  我没有成功地从 python 中获取信息:

    还记得我说过擦除命令是唯一看起来在运行的东西吗? 我已经确认这是因为,我添加了一些跟踪/打印消息,它们会停止代码工作,而不是仅仅打印...据 UNIFLASH 判断,很快就会停止。  我怀疑在尝试打印字符串(例如整个 python 中使用的数据参数)时、有一些 upsets 打印(ASCII 00? 应该为空、但这是我的主要怀疑)- c#中也发生了同样的情况、但我已经完成了格式化、以十六进制格式将其全部输出。  一旦我在 python 中得到了这种支持、我就应该能够准确地看到正在发生的情况、而不会破坏它!  重要的是、我还将能够查看 UNIFLASH 向 python 发送的参数。

    今天、我花了大部分时间重新查看我的 CCS 项目-恢复到使用我自己的 IWR 代码而不是工具所能达到的速度、因为现在应该没有太多时间让这些位正常工作。  我现在再看一下 python、看看我是否可以从其中获取信息。  这应该能解决一切问题!  我将在我使其工作后向您更新。

    非常感谢

    Alan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Alan:

    在与固件团队一起查看您的代码时、NAK 可能来自 CRC、这似乎是不正确的。 您能否验证您是否正在正确计算此值?

    此外、如果您要在 CCS 中修改代码、使用 JTAG 连接来实际调试代码似乎更简单、更有用。 您是否计划仅将代码完全加载到 SRAM 而不使用调试模式? 我认为代码修改将很难做到这一点。

    此致、

    杰克逊

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Jackson、

    是的、已找到 CRC 错误(但我将再次检查以确保正确)。  不过、不要认为它有任何改变、仍然得到了 NAK 回复。 (请参阅附件、几篇文章之前)。 我最初对消息进行硬编码-然后进行参数化-但忘记重新执行校验和以进行匹配。

    我一直在努力通过 python 从 UNIFLASH 获取更多信息:这并不容易! 它对确切的格式非常挑剔-任何问题甚至是轻微的错误、它要么不输出任何内容、要么使该位(可能还有其他位)停止工作。  此外、修改 python 以便我可以单独使用它(在 Visual Studio 中、所以可以使用断点等)、我可以获得我想要的所有内容(必须更改以打印语句)非常合理的格式-包括从其中获取准确的数据。  但是、UNIFLASH 版本中也不能使用相同的功能。 我认为这与打印任何 ASCII 值为0的字符串有关-字符串(甚至所有字符串)无法输出。  您可以看到、我已经在 c#(附件)中管理好了它、我可以在独立的 python 中接近它、但不能通过 UNIFLASH。  欢迎您提供有关如何执行此操作的任何意见!

    因此、这就是该位需要花费更长的时间的原因。

    至于修改代码-是的、在为 IWR 编写新代码时、我将使用 CCS 和 JTAG、直到可以看到代码编译、运行并执行我想要的操作。  但是、我将使用 IWR 作为数据收集系统、在 PC 上开发后处理。  因此、我将需要一个工具-它可以加载代码(从 CCS)、然后接受并分析 IWR 的输出。  这与 mmWaveStudio 允许您执行的操作没有太大不同、只是我需要完全控制所有处理。 如果成功、则返回 CCS、将 post=处理重新写入(很可能) DSS。

    谢谢!

    Alan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    嗯、我认为我已经得出结论、我无法再利用 UNIFLASH 和 Python:在 send_packet 中添加消息(最低级别、为所有其他人所用)应该会在发送数据时提供大量输出。  它告诉我已发送擦除命令、但不会再发送- UNIFLAHS GUI 中可能还有其他一些在主下载期间停止输出的内容。

    但是、在 python 和您在这里提供的内容之间、应该有足够的空间来确定协议应该执行的操作。

    我现在所怀疑的是、尤其是因为我必须离它很近、所以我的代码(此处的 c#不是特别友好)实际上并不是在正确握手。  它可能看起来好像发送的一切正常、但并非所有块实际上都在传递。  因此、引导加载程序中的计数与 open 命令中发送的文件长度不匹配-因此整个过程失败。

    所以-我认为你可能已经尽力了、剩下的问题肯定在我的领域、而不是你的领域、所以最好的事情可能是现在关闭这个线程。

    非常感谢您的帮助和意见!

    Alan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    ...我在之前的回复中选择了"已解决"、但看起来不是。

    我可以添加,那么...写入 SFLASH 现在可以工作!!  它确实没有发送它看起来的样子,一些数据块丢失了。 不过、SRAM 变体仍然无法正常工作、但必须非常接近。

    我认为我不能通过更改 python 中的存储类型来使其正常工作-明天第一份检查的工作。  我想知道您是否已经尝试过这种方法?  具体而言、我想确保 SWRA627 (第13页)的表述正确无误:

    1) 1)请勿发送整个(bin 文件) crc...您是为 SFLASH 发送的

    2) 2)下载完成后(0x22关闭)- IWR 应从 SRAM 运行。 无需执行任何其他操作、也无需更改 SOP 设置等。 我已确保已发布 COM 端口、但可视化工具无法连接到任一端口。

    谢谢

    Alan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Alan、

    1) 1)这是正确的。将映像发送到 SRAM 时、需要去除通常附加到整个映像的4字节 CRC。

    2) 2)这也应该是正确的。 这是您发送到 sflash 时也发送的最后一条命令吗? 除发送的存储命令和上述 CRC 之外、序列应相同。  执行此操作时、引导加载程序是否会发出错误标志/LED?

    此致、

    杰克逊

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Jackson、

    就我所见(我知道这是一个危险的说法!),我的闪存和 SRAM 代码是相同的,除了命令细节和最后的 CRC。 因此,如果我有闪存工作,似乎没有什么不对的地方…希望。

    简单地说、我将通过以下方式测试我的闪存负载:

    SOP5、ERASE / SOP4、可视化工具失败/SOP5、闪存下载/SOP4、直接显示。  过程中会进行各种电源循环。

    正在测试 SRAM 下载-发送数据并关闭、然后关闭 COM 端口、或者只需退出我的代码。  正如我所理解的(SWRA 图4、右侧)、IWR 现在应该正在运行-但可视化工具无法连接。

    下面是我发送的内容、SRAM 模式的快照(前2条命令是 break、用于打开 COM 端口和 ping、我使用它来请求 ACK、以开始我必须执行通信序列的方式、以确保我的代码等待命令之间的 ACK。  相同的闪存和 SRAM):

    命令编号:3:{Open to SRAM}metaImage 编号:1 metaImage 类型:4
    <00><13><76><21><00><04> <80><00><00><00><04><00><00><00><00><04><00><00><00><00><00><00><00>

    4:{getStatus}
    <00><03><23><23>

    5:{Write to SRAM}metaImage 编号:1 metaImage 类型:4
    块:0 bin 文件 addr:00000000
    <00> <00><26>
    <4D><53><54><52><03><00><00><00>:<37><00><00><00> <9c><4c><19>
    <62> <9b> <80> <04><00>:<01><00><00><00><00><00><00><51><35>

    1347:{Write to SRAM}metaImage 编号:1 metaImage 类型:4
    块:1342余数
    bin 文件 addr:0004EA20
    <00><63><09><26>
    <4e><7f><00><88><21><80><00>:<8e><21><80><00><88><21><80><00>
    <80><21><80><00> <21><80><00>: <21><80><00> <21><80><00>
    <21><80><00><00><00><00><00><00>: 81><00><00><00><00><00><00>
    0c><00><00><00><00><00><00><00><00><00>:<00><00><00><00><00><00><00><00><00><00>
    <00><00><00><00><00><00><00><00><00>:<00><00><00><00><00><00><00><00><00><00><00>
    <00><00><00><00><00><00><00><00><00>:<00><00><00><00><00><00><00><00><00><00><00>

    1348:{接近 SRAM}
    <00><07><04><22><00><00><00><00><04>

    所有回复都带有 ACK (在发送下一条命令之前...实际上,您可以看到它在 SFLASH 开始时暂停,这可能是引导加载程序的一些内部工作)

    我还在不同的地方收到了状态请求-不会影响工作(如中所示、可以使用中的状态请求进行刷写)。  请注意、关闭命令使用 metaImage 类型4、即 metaImage1作为参数。

    我没有任何错误(DS1、红色?) LED、仅绿色表示电源、黄色表示 NRST。

    最后、对于此条目-我已编辑 mmwaveProgFlash、以便在整个过程中使用 SRAM。  这会运行并报告成功...但可视化工具无法连接(uniflash 关闭以释放 COM 端口),因此最终结果与我自己的代码相同。  这就是为什么我想知道您是否已经成功地向 RAM 写入数据?  我对 python 的知识没有做出任何声明、而且由于 Uniflash 未能告诉我它在做什么、我无法准确地确认它真正发送的内容。

    非常感谢!

    Alan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Alan:

    我之前已修改 Uniflash 内的 mmwaveProgFlash 以成功写入 SRAM。 但我仅尝试在 uniflash 中运行该代码、其中 SRAM 选择不是直接发送的单个命令。 我认为没有另一个不同之处。 很明显、您对闪存代码的加载与对 SRAM 代码的加载之间的唯一区别是、您发送命令0x26而不是0x24来写入 SRAM、而不是 SFLASH?

    您还可以打开 TeraTerm 或 PuTTy 或一些简单的终端、以查看 COM 端口是否处于活动状态并做出响应、而不是尝试连接到可视化工具(有时可能有点不方便)。 您应该会看到一个提示符、它应该会回显您的字符。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Jackson、

    不、这不是唯一的区别:

    • 表2、open 文件在此命令中也具有存储类型-我认为 python 也是这样做的(第426行 ish)
    • 此外、根据 SWRA、close 命令 应发送存储类型-但 python 应发送 mataImage ID

    我想我现在已经在 open 和 send 命令以及 close 命令中尝试了所有闪存/ SRAM 代码组合。  

    我自己的代码以终端形式启动、因此我可以向 IWR 发送命令(在 SOP4模式下)。  要进行检查、我还使用了 PuTTY -下载 SRAM 后两者都没有响应。

    我想在下载结束时还有其他需要的东西吗? 无论闪存还是 SRAM (条形码在打开、下载和关闭以及 CRC 中发生变化)、其他所有内容都是相同的、因此似乎仍有一些东西会触发图4中的"eclipse MMS ROM"位? 相反,它可能处于“永远等待”状态...但命令代码差异应该移至右侧,即 BOOTMODE-UART?

    如果没有其他内容、我必须遵循图9协议、否则闪存编程将无法正常工作。  一定是剩下的小事-因此很难找到!

    顺便说一下,作为硬件检查,我确实看到了红色的 LED… 我返回 SOP4以检查串行通信、必须已擦除闪存、而不是重新发送。  一旦我将闪存重新放入(我的代码、而不是 UNIFLASH)、所有器件就会按预期运行。

    谢谢

    Alan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    从字面上看图4…

    右上角的问题框询问"Boot Over UART Cmd"。  这是我唯一可以看到上述内容的地方(SWRA 和两个热插拨)。  第13页启动模式- UART 没有提到任何其他命令、它可能希望 UART 启动命令已经发送、然后才会在本节中讨论下载过程?

    我所做的可能是 A-OK -写入 SRAM。  发送后、我还没有告诉 IWR 如何处理它?

     只是一个想法、因为我已经离开了其他人了!

    谢谢

    Alan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    不需要通过 UART 命令进行特定引导、引导加载程序应从写入 SRAM 命令中获取该引导。

    在 Uniflash 代码中、我看到的唯一其他区别是、加载 SRAM 时、我们在查找校验和时读取的是4个字节而不是1个字节。 我并不完全确定为什么这是不同的、但您的代码中也有这样做吗? 可能仍然存在一些无法完全检查的计时问题?

    此致、

    杰克逊

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Jackson、

    不、我也不明白这一点!  它进入 send_command、然后进入 receive_packet。  似乎是说引导加载程序在闪存和 SRAM 下载之间提供不同长度的答复?  据我所见、我始终得到 ACK 应答、这是5个字节、而不是1或4个字节。  是的、我在这里肯定会有问题、但我不知道是什么。

    我得到的-它在同一区域-是发送闪存或 SRAM 之间的差异之一。  闪存将4个字节添加到文件长度(预编译的04ea80)中、这就是它决定是否发送 CRC 的方式。  如果它说的闪存为4、SRAM 为0、我可能理解它、即查找正在发送的额外字节。  但是、由于它在 Receive_packet 中使用、它必须是指引导加载程序返回的内容、而不是我要发送的内容?

    时序-很好地修复了闪存下载的作用。 当我将每个命令放在一起时、我会为它提供一个数字。 当从 com 端口接收到任何内容时,我会报告收到消息时存在的命令编号...。  通过这种方式、我可以查看是否有任何内容丢失或退出。  我已经浏览了整个事务(闪存和 SRAM)、一切看起来都不错、没有任何遗漏或不有序。  每次我得到的是5个字节、即 ACK 应答、然后我发送下一条命令、直到全部发送。

    在这里、我确实看到加载程序的答复有所不同、是状态命令(例如、在执行 open 命令之后):

    • 闪存- 4字节、00-03-40-40、即成功
    • SRAM - 7字节00-06-40-00-00……或者有时为有效载荷/CRC 全为零,我认为这类似于“谢谢询问,但还没有发生任何事情”

    希望那里有一些东西指出仍然有什么问题...

    谢谢

    Alan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    让我再次检查、以验证是否存在其他更改。 但我看不出哪里可以。 为了后续目的、您能否再次确认在加载到闪存时、加载的4字节 CRC 被移除的情况下加载映像? 您是否曾尝试使用 CRC 加载映像、只是为了验证映像是否也失败? 另一种方法是(将 CRC 去除符号的版本加载到闪存中失败)。 我只要求几个调试点、以确保正确发送命令。  

    此致、

    杰克逊

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Jackson、

    是的-请务必咨询!  我们必须努力做到这一点,因为这是一个微不足道和明显的事情,所以很难找到。。。你需要继续帮助我的就是我发送的信息,所以我总是很乐意添加信息。  正如我已经向我展示了软件的调试功能、运行软件和复制相关位只是一个问题。

    对其来说-我已经打开了(包括长度),发送了最后一个块...包括块长度和/或不是校验和,以及关闭了所有组合。  嗯,我没有包括带校验和闪存版本...它与 SRAM 版本完全一样,但代码发生了变化(26 > 24),并且工作正常。  我还包括了我对你们的俾格米人所做的工作-这也不起作用。

    SRAM 无校验和:

    命令编号:3:{Open to SRAM}metaImage 编号:1 metaImage 类型:4
    <00><13><76><21><00><04> <80><00><00><00><04><00><00><00><00><04><00><00><00><00><00><00><00>

    1347:{Write to SRAM}metaImage 编号:1 metaImage 类型:4
    块:1342余数
    bin 文件 addr:0004EA20
    <00><63><09><26>
    <4e><7f><00><88><21><80><00>:<8e><21><80><00><88><21><80><00>
    <80><21><80><00> <21><80><00>: <21><80><00> <21><80><00>
    <21><80><00><00><00><00><00><00>: 81><00><00><00><00><00><00>
    0c><00><00><00><00><00><00><00><00><00>:<00><00><00><00><00><00><00><00><00><00>
    <00><00><00><00><00><00><00><00><00>:<00><00><00><00><00><00><00><00><00><00><00>
    <00><00><00><00><00><00><00><00><00>:<00><00><00><00><00><00><00><00><00><00><00>

    1348:{接近 SRAM}
    <00><07><04><22><00><00><00><00><04>

    带有校验和的 SRAM:

    命令编号:3:{Open to SRAM}metaImage 编号:1 metaImage 类型:4
    <00><13><7A><21><00><04> <84><00><00><00><04><00><00><00><00><04><00><00><00><00><00><00><00>

    1347:{Write to SRAM}metaImage 编号:1 metaImage 类型:4
    块:1342余数
    bin 文件 addr:0004EA20
    <00><67><7D><26>
    <4e><7f><00><88><21><80><00>:<8e><21><80><00><88><21><80><00>
    <80><21><80><00> <21><80><00>: <21><80><00> <21><80><00>
    <21><80><00><00><00><00><00><00>: 81><00><00><00><00><00><00>
    0c><00><00><00><00><00><00><00><00><00>:<00><00><00><00><00><00><00><00><00><00>
    <00><00><00><00><00><00><00><00><00>:<00><00><00><00><00><00><00><00><00><00><00>
    <00><00><00><00><00><00><00><00><00>:<00><00><00><00><00><00><00><00><00><00><00>
    <63> <9f>


    1348:{接近 SRAM}
    <00><07><04><22><00><00><00><00><04>

    闪存、无校验和

    命令编号:4:{打开到闪存}元映像编号:1元映像类型:4
    <00><13><74><21><00><04> <80><00><00><00><02><00><00><00><00><04><00><00><00><00><00><00>

    1348:{Write to Flash}metaImage 编号:1 metaImage 类型:4
    块:1342余数
    bin 文件 addr:0004EA20
    <00><63><09><24>
    <4e><7f><00><88><21><80><00>:<8e><21><80><00><88><21><80><00>
    <80><21><80><00> <21><80><00>: <21><80><00> <21><80><00>
    <21><80><00><00><00><00><00><00>: 81><00><00><00><00><00><00>
    0c><00><00><00><00><00><00><00><00><00>:<00><00><00><00><00><00><00><00><00><00>
    <00><00><00><00><00><00><00><00><00>:<00><00><00><00><00><00><00><00><00><00><00>
    <00><00><00><00><00><00><00><00><00>:<00><00><00><00><00><00><00><00><00><00><00>

    1349:{Close to Flash}
    <00><07><04><22><00><00><00><00><04>

    答复是:

    1348:{Write to Flash}metaImage 编号:1 metaImage 类型:4
    块:1342余数
    rxLength:5字节
    <00><04> <00>


    命令编号:1349:{Close to Flash}rxLength:5字节
    <00><04><33><00><33>

    NACK? 说它失败了吗? 是的,SOP4无响应...红色 LED 亮起。

    我在每次试验之间按 NSRT (SW2)按钮-然后发送中断以打开通信。


    我对 python 做了什么使其成为 SRAM (UNIFLASH 6.4.0)...

    属性映射['comport']='COM37'
    属性映射['comport']='COM4'
    属性映射['MemSelectRadio']='SlFlash'
    属性映射['MemSelectRadio']='SRAM'
    properitiesMap[DownloadFormat']= True


    DEF _SEND_START_DOWNLOAD (self、file_id、file_size、max_size、mirror_enabled、storage):
    存储="SRAM"

    默认下载文件(self、filename、file_id、mirror_enabled、max_size、storage、imageProgList):
    存储="SRAM"

    Close not changed (关闭未更改)-它发送 metaImage ID、而不是存储类型

    这不起作用、即发送、然后尝试与 COM 端口通话-无回复。

    希望这就是你想要的一切...

    谢谢

    Alan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    需要说明的是、在仅修改属性映射中的这两行、然后通过 uniflash 运行时、SRAM 加载不起作用? 这是奇怪的,因为这在过去是绝对有效的。 请使用我在下面包含的文件尝试该操作。 这只是 IWR6843的 OOB 演示、删除了4字节 CRC。 我只修改了第60行以设置 属性 Map['MemSelectRadio']='SRAM'。 否则、我会遵循标准的 Uniflash 加载过程。 加载完成后、我就能在增强型 UART 线路上获得响应。 然后、当我复位器件时、响应崩溃、表示程序正在运行、但闪存已按预期正确擦除。 如果这在您的设置中不起作用、则会出现另一个问题。 还是我不理解您之前的消息?

     e2e.ti.com/.../xwr6843ISK_5F00_mmw_5F00_demo_5F00_noCRC.bin

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Jackson、

    感谢您提供该文件-检查时、长度为536640。  嗯、这也不起作用。  正如您所说的、我只修改了"顶部"python 中的 SRAM (和 COM 端口)。  这就是 UNIFLASH 6.4。  我对 UNIFLASH 7.1.0.3796也做了同样的操作、结果也一样。

    在我自己的代码中、它的运行方式与1843预编译相同(现在精确的240个数据块数、不是余数)、并获得对 close 命令的 ACK。  也不奏效。

    UNIFLASH 说我的 IWR 是 REV C R2101050、背面的板编号是6050400155。

    作为另一项检查、我已将 UNIFLASH 重新设置为"未经编辑"、并对闪存进行了编程。  在 SOP4中引导会产生红色 LED -因此我想 bin 文件在1843上实际上不起作用?  也就是说,com 端口会进行回显-它不会执行任何操作...对于正常的预编译,如果您说发送“?”,它会返回“无效命令”或具有此效果的字。

    无论是闪存还是 SRAM、UNIFLASH 都可以说它已成功完成。

    希望这能让我们找到一个地方!

    非常感谢

    Alan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Alan:

    我忘记了您使用的是1843、而不是6843、因此我发送的文件是6843。 只需再次检查您使用的文件是否确实是1843特定映像、并从 该文件中删除4字节 CRC? 这很奇怪、Uniflash 修改也不起作用、我本来希望它能够正常工作。 我实际上没有在 IWR1843上对此进行过测试、但引导加载程序函数应该相同。 您是否希望看到您正在使用的确切图像以及您要加载到的确切器件(1843与1843AOP)?

    谢谢、

    杰克逊

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Jackson、

    IWR1843、不是 AOP 版本、文件是您发送的文件、或者来自工业工具箱的18xx 预构建.bin (4-8-0或4-9-0、相同内容)用于 OOB 演示。  针对 SRAM 明确删除了 CRC。

    我怀疑文件内容基本可以,因为闪存下载正常。。但是问题的级别太明显了,不容易看到。

    使用:SWRA 图4表示首先将 metaImages 发送为 BSS、然后是 MSS/DSS、而文件内容为 MSS-BSS-DSS。  我无法想象这一点、因为协议似乎允许任何顺序、因为每个 metaImage 都标记为它的内容和放置位置。  我假设引导加载程序设置了所有存储器(即将下载存储在 SRAM 中)、然后在一个处理器上按"开始"(图4显示 MSS)、该处理器随后会启动所有其他内容。 同样、下载顺序无关紧要。

    但是、由于闪存的下载(您的文件)至少有正在运行的内容- COM 端口回显、但未正确处理消息。  只下载闪存、而不是 SRAM、无论是 UNIFLASH 还是我自己的 SRAM。

    一个类似的想法:您知道您以前使用的 UNIFLASH 版本吗? 我不想有人在更新过程中改变了什么?  我还没有时间尝试这个-但我看到我可以从 TI 网站下载旧版本。  今天下午、我将尝试到达那里。

    另外(但相关):在等待解决该位时、我在 CCS 和 JTAG 中继续进行代码开发。  我可以重新构建 SDK OOB (有趣的是、这不会生成与预编译相同的 bin 文件)。  实际运行需要一个混乱的过程-还没有很好的排序,我似乎不得不暂停和取消暂停 MSS ...这可能是一个加载顺序问题,我必须解决,但它运行和可视化工具工作正常。  因此、除了下载到 SRAM 之外、所有的开发过程似乎都正常工作。

    如果有时间、我会告诉您、如果我有时间使用旧的 UNIFLASH 变体、我会告诉您。

    非常感谢

    Alan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好!

    Uniflash 旧版本:

    4太旧了、没有 mmWave 目录和 python (我可以看到)

    5更像6和7、但仍不适用于 SRAM 下载。  我尝试只更改"top " 2行、并分别将 storage="SRAM"放入每个命令中...因为我不知道 Uniflash 向它们发送了哪些参数。

    引导加载程序本身是否有任何更新?  我不能告诉您有关此内容的任何信息、除非有某种方法询问它是什么版本号等。 鉴于闪存下载正常(Uniflash 和我自己的代码)、我们应该使大部分协议正确、它是否指向引导加载程序末尾的某个内容?  要么是缺少命令、要么是没有执行图4所示的操作、即执行下载、然后执行代码运行。

    只需确认-尽管我无法获取 Uniflash 以在其运行时提供更多详细信息、 但我自己的代码让我看到每个命令都会返回一个 ACK、因此、打开、下载和关闭所有命令似乎都被接受。

    我们接下来可以尝试什么?  我的工作确实需要此功能。

    谢谢

    Alan

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Alan:

    我们对此进行了更深入的研究。 我们确认了在 IWR1843器件上看到的行为与您相同。 ROM 引导加载程序中似乎存在影响此器件的错误。 即使正在加载映像解析、也不会调用它、这就是器件无法引导的原因。 遗憾的是、由于该错误位于 ROM 引导加载程序中、因此我们目前无法执行任何操作来更改它、并且此功能将无法修复。

    希望您能够顺利处理 JTAG 负载? 我仍然认为这是为器件开发代码的最佳方法、因为您可以单步执行并暂停。 如果您对此有任何疑问、请告知我们。

    此致、

    杰克逊

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Jackson、

    哦、嗯、至少我们已经发现了正在发生的情况!

    当您说它不会有修复程序时、我假设您是指"这个线程"?  希望何时(如果)有器件更新、那么引导加载程序将同时修复?  我这样说是因为,如果我的研究工作能够实际进行,那么就需要设计/制造设备来实现我要做的事情-可能需要大量的工作...这种高度集成的芯片帮助了我,所以在其他地方做的事情就更少了。 并且希望 以合理的价格购买大量器。  如果我是负责设计整个系统的人、我可能不 会在 主器件中使用闪存或连接到主器件、而是仅使用一个非易失性存储器来完成整个过程、因此我希望使用引导加载程序下载到 IWR。

    实际上、我在 CCS 和 JTAG 以及将 COM 端口用于配置和数据方面取得了合理的进展。  由于我能够真正了解 IWR/TIROS 的编码并实现所需的更改、因此在开始时会有许多迭代。  这一切都很正常、我准备使用 IWR 数据采集系统进行研究、理想情况下、我将拥有一个用于编程+配置+数据采集和分析的工具。  但是、在无法解决的方法上似乎存在问题、因此我只需使用不同的方法。  这就是适合您的研发工程!

    非常感谢您坚持这一点、直至我们了解根本原因!

    Alan