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.

[参考译文] AWRL6432:UART 引导加载程序流程:型号差异

Guru**** 2694555 points

Other Parts Discussed in Thread: UNIFLASH, AWRL6432, IWR6843, IWR1642

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

https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1589864/awrl6432-uart-bootloader-flow-variant-differences

器件型号: AWRL6432
主题中讨论的其他器件: UNIFLASHIWR6843、IWR1642

转换器
 
 
 
 

 

尊敬的 TI 支持团队:

我负责支持 AWRL6432 器件的 UART 编程流程。 我注意到、在“C:\ti\uniflash_9.1.0\deskdb\content\TICloudAgent\win\ccs_base\mmwave_Gen3\mmWaveProgFlash.py“和用户手册 swru599c.pdf 的第 200 页之间传递给“close file“(0x22) 命令的预期参数不匹配。

我应该使用文件类型还是存储类型?  

我还遇到了 Gen1 器件上的其他不匹配问题、根据 python 脚本、应该所有器件都具有文件类型。 但是、SWRA627 规定 IWR6843 应具有存储类型。  

您能否确认哪一个是正确的?

是否可以跳过 Get STATUS 命令并仅检查是否返回了 ACK 响应? 这种方法是否 适用于所有传感器器件?

 

提前感谢您的支持。

 

此致、

Luca Zanuttini

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

    尊敬的 Luca:

    感谢您联系我们。 请允许我们的引导加载程序专家在几天内查看此内容并返回给您。

    此致、

    Vignesh K.

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

    转换器

    尊敬的 Vignesh:

    有什么关于这个话题的新闻吗?

    此致、

    Luca.

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

    尊敬的 Vignesh:

    很抱歉再次打扰您、有任何更新吗?

    此致、

    Luca.

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

    嗨、Luca、

    很抱歉耽误你的时间。 我将在今天晚些时候作出回应、提出一些想法和建议。

    此致、

    Kristien

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

    嗨、Luca、

    我应该使用文件类型还是存储类型?  [/报价]

    对于 AWRL6432、Close download 命令不需要文件类型、因为它指示文件下载结束。 对于存储类型、在大多数情况下、您应使用关闭下载 (SFLASH)、即 0xAA | 0x0007 | CHK_SUM | 0x22 | 0x2、除非下载到 SRAM。

    是否可以跳过 GET STATUS 命令并只检查是否返回了 ACK 响应? 此方法是否 适用于所有传感器器件?

    GET STATUS 命令不是必需的、因此如果下载时间很长、可以将其排除。 但是、 如 Python 脚本所示、只有在接收到 NACK 并发送最后一条命令时、我们才调用 GET STATUS、因此首先这应该几乎不会影响下载时间。

    此致、

    Kristien

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

    尊敬的 Kristien:

    非常感谢您的答复。

    所有传感器器件的近距离下载是否相同? 如果是、这是否意味着 Python 脚本中存在将文件类型用作关闭下载参数的错误? 我是否应该担心脚本中的其他已知错误?

    IWR1642 引导加载程序流是否属于异常? 我从 SWRA563 - 2017 年 6 月 (https://www.ti.com/lit/an/swra563/swra563.pdf) 中看到、文件类型是以比例尺的形式传递的。

    此致、

    Luca.

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

    嗨、Luca、

    并非所有雷达器件都使用关闭下载命令。 对于 IWR1642 等第 1 代器件、文件类型 (meta_img1、meta_img2 、meta_img3 或 meta_img4 ) 是关闭下载命令的一部分。 注意:xWR18xx 和 xWR68xx 器件是第 1 代系列的例外情况、需要在关闭下载命令中包含存储类型。 对于第 2 代器件、它利用 UART+XMODEM 来传输映像、因此这不遵循其他几代产品的自定义命令。 对于第 3 代和第 4 代器件、 为关闭下载命令指定存储类型 (SFLASH 或 SRAM) 而不是文件类型。

    希望这澄清了引导加载程序命令的差异、但如果您有任何其他问题、请告诉我。

    谢谢、

    Kristien

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

    转换器
    转换器

    您好 Kristien、

    很抱歉坚持,但我注意到 Gen3 的脚本设置了关闭下载命令的文件类型,而不是存储类型:

    这是脚本中的错误吗?

    我还在 Gen1 器件的脚本中注意到、无论 ACK 响应如何、始终会发送状态命令。 我可以像第 3 代和第 4 代器件那样跳过状态命令吗?

    此致、

    Luca.

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

    嗨、Luca、

    脚本中是否有错误?

    我在内部向 UniFlash 团队仔细检查、发现这确实是 UniFlash 实现中的一个错误。 但是、这在文件下载过程中不会导致任何问题、因为为打开文件命令指定文件类型对于文件下载更重要。

    我还注意到在 Gen1 器件的脚本中、无论 ACK 响应如何、都会始终发送状态命令。 我可以像第 3 代和第 4 代器件那样跳过状态命令吗?

    您应该能够排除 GET STATUS 命令、因为在 UniFlash 脚本的下载过程中不会使用返回的状态。

    谢谢、

    Kristien

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

    尊敬的 Kristien:

    我期待您的反馈。

    同时、您是否还可以确认是否应将文件类型或存储类型传递给 IWR6843 的关闭命令? 事实上,它也是一个 Gen1,但 SWRA627 指出,应该使用存储类型,而不是文件类型。 顺便说一下、您是参考引导加载程序流程应用手册还是内部文档? 我担心、 由于复制和粘贴问题、诸如 SWRA627 之类的 AN 可能不正确。  

    无论如何,我同意你的意见,这不应该对编程产生任何影响。 我只是想确保一切都符合官方规范。

    此致、

    Luca.

    转换器

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

    嗨、Luca、

    我会注意到、器件代数并不总是明确定义、因此可能会有一些奇怪的例外情况。

    同时、您是否还能确认是否应将文件类型或存储类型传递给 IWR6843 的 close 命令?

    xWR68xx 和 xWR18xx 器件是第 1 代器件的一个例外、因为它们是在 xWR12xx、xWR14xx 和 xWR16xx 器件之后发布的。 对于  xWR68xx 和 xWR18xx 器件、close 命令确实需要指定存储类型、而不是文件类型。

    顺便说一下、您是指的是引导加载程序流程应用手册还是内部文档? 我担心、 由于复制和粘贴问题、诸如 SWRA627 之类的 AN 可能不正确。  [/报价]

    我指的是以下文档:

    如果您有任何其他问题、请告诉我。

    谢谢、

    Kristien

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

    您好 Kristien、

    我注意到、对映像文件进行编程后、如果不重新启动串行通信(包括复位脉冲)、则无法下载新的映像文件。 这是预料之中的吗? 我的意思是、是否可以依次下载多个映像文件、例如:

    打开文件(图像 1)

    发送数据(图像 1)

    关闭文件(图像 1)

    打开文件(图像 2)

    发送数据(图像 2)

    关闭文件(图像 2)

    而不是:

    打开文件(图像 1)

    发送数据(图像 1)

    关闭文件(图像 1)

    复位脉冲

    等待 ACK

    打开文件(图像 2)

    发送数据(图像 2)

    关闭文件(图像 2)

    此致、

    Luca.

    转换器

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

    嗨、Luca、

    对于第 3 代器件、您需要 按照刷写次级引导加载程序和备份映像的说明、在加载映像之间复位器件。 对于 Gen 4 器件、我需要仔细检查是否仍需要复位、但如果尝试一次刷写多个映像、则不需要复位。

    此致、

    Kristien  

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

    尊敬的 Kristien:

    非常感谢您提供的信息。

    根据您分享的最后一个链接、图像文件大小似乎高达 512KB。 但是、从 python 脚本中、我可以看到以下值:

    Gen1、Gen3:

    MAX_FILE_SIZE             = 1024*1024
    MAX_APP_FILE_SIZE        = 166912

    第 4 条

    MAX_FILE_SIZE             = 512*1024*1024
    MAX_APP_FILE_SIZE        = 5120*1024*1024

    这是脚本的错误还是分区大小并非总是固定为 512KB? 我假设打开文件命令在地址超出预期分区时返回 NACK、您能确认这一点吗?

    再次感谢您的帮助。

    此致、

    Luca.

    转换器