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.

[参考译文] CC3220SF:SLImageCreator Quot;Timeout reading data"

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1452670/cc3220sf-slimagecreator-timeout-reading-data

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

工具与软件:

大家好!

 

在我们的生产中使用 SLImageCreator 刷写最终固件时遇到问题。
我们使用 CC3220SF Wifi MCU 和 USB 闪存。 Uniflash 版本为8.8.1。

该错误有以下症状:

 

映像编程:98%(1572864/1593024)

映像编程:98%(1576960/1593024)

映像编程:99%(1581056/1593024)

图像编程:99%(1585152/1593024)

图像编程:99%(1589248/1593024)回溯(最近一次调用):

 文件"SLImageCreator.py"第5740行、位于中

 第5735行的"SLImageCreator.py"

 命令行中的文件"SLImageCreator.py"第5704行

 COMMAND_PROJECT_PROGRAM 中的文件"SLImageCreator.py"第4439行

 program_image_from_project 中的文件"SLImageCreator.py"第3010行

 program_image 中的文件"SLImageCreator.py"第3221行                   

 FS_PROGRAMMING 中的文件"slbootloader\slbootloader.py"第802行

 _FS_PROGRAMMING_CHUNK 中的文件"slbootloader\slbootloader.py"第741行

 expected_ack 中的文件"slbootloader\slbootloader.py"第320行

 _READ_DATA 中的文件"slbootloader\slbootloader.py"第352行

slbootloader.slbootloader.BootLoaderError:

错误:SLImageCreator.exe:BootLoaderError、Timeout reading data

[9388]由于未处理异常、无法执行脚本'SLImageCreator'!

 

这些误差仅偶尔在某些器件上出现。 其他器件不存在此错误。
如果器件上发生该错误、其中一些器件可以在之后引导、而另一些器件则不能引导。
在安装最终固件之前、我们还刷写了测试软件、可以刷写而不会出现任何问题。
我们使用两个不同的固件执行了刷写过程、以排除有故障的固件。 什么是
显然、闪存过程始终与特定固件在同一点停止。
例如、该过程在固件 V35中停止在1589248字节、而 V32在1527808 (s)停止。 就这么简单
取决于固件大小。 对我来说、这表明电缆可能没有问题
或波特率。
通常、闪存过程需要很长时间才能完成最后一个字节。 我不知道闪存工具在做什么
方法。 验证? 对图像进行加密、可能吗? 最后一个流程出了问题。
WiFI MCU 映像已加密。 固件中的所有其他文件则不会如此。

可以正常运行  

测试运行编号  

传感器名称  

详细信息日志  

V35  

1、2、3  

a.

99%(1589248/1593024)  

V35  

1.  

B.  

99%(1589248/1593024)  

V35  

1、2、3  

C.  

99%(1589248/1593024)  

 

 

 

 

V32  

1、2、3  

a.

99%(1527808/1529712)  

V32  

1、2、3  

B.  

99%(1527808/1529712)  

V32  

1、2、3  

C.  

99%(1527808/1529712)  

我们还使用 out_of_the_box 演示固件进行了测试、所有器件均成功! 它看起来与相关  
固件出现故障。

是否有办法获得有关该误差的更多详细信息? 比如在闪存时创建的更详细的跟踪文件吗?


非常感谢!

Sebastian

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

     我们观察到、如果我们使用 mcuimage.bin 的虚拟证书、则刷写过程是成功的。

    但是、有时会发生以下错误:

    error:slbootloader.slbootloader:--获取存储列表时出错  

     

    如果我们从 Uniflash 项目中删除所有文件、并仅使用虚拟证书对 mcuimage.bin 进行加密、则不会发生错误。

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

    如果我们仅刷写 mcuimage.bin、但使用密钥也能成功完成刷写过程。 所以文件数量和/或闪存大小存在相关性。

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

    尊敬的 Sebastian:

    是的、这可能与数据传输问题有关、但很难说。 您是否检查了 UART 信号的完整性(例如使用带有有源探头的示波器)? 对于 Uniflash CLI、可以使用详细模式(-e)、但我认为这没有太大用处。 是的、当 UART 数据传输完成时、会根据签名验证映像并创建文件系统。 这可能需要一些时间、具体取决于 SPI 闪存的状态。

    • 您是否使用供应商身份验证或拥有来自受支持 CA 的代码签名证书? 如果使用第二个选项、您可以尝试嵌入式编程
    • 您是否使用命令列表中的 SPI 闪存
    • 是否进行了 SPI 闪存交换以确定问题是否与某些特定 SPI 闪存芯片无关?
    • 您使用什么器件来刷写 CC3220? (XDS110、FTDI 等)?

    1月

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

    您好、Jan:

    感谢您的答复!

    • 我们尚未实现 UART 信号完整性。
    • 我们使用供应商身份验证
    • 我们使用来自命令列表的闪存、但闪存的大小更大(MX25R6435F)
    • 我们未交换闪存芯片  
    • 我们使用 USB-UART 桥接器 CP2105进行刷写

    Sebastian

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

    尊敬的 Sebastian:

    您可以尝试使用 LaunchPad 中的"经典"FT232RL 或 CDC (XDS110)吗? 我在使用 Silabs CP21xx 芯片时遇到过很多奇怪的问题。 在某些应用中、CP21xx 芯片的行为是不可预测的。

    1月

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

    您好、Jan:

    好的、我们明天将尝试一下、看看是否有什么不同。

    谢谢!

    Sebastian  

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

    我们尚未能通过 JTAG 进行刷写。
    使用我们的硬件并不容易做到这一点。 我们还在努力!

    激活详细模式(-e) SLImageCreator 时也遇到问题
    似乎不支持这一点?

    我们进行了更多闪存测试。 我们使用始终可以成功刷新的器件(A)、而始终出现故障的器件(B)或(C)有时仅显示错误。
    我们对几个大文件进行了两次测试、对许多小文件进行了一次测试。
    我们希望了解大图像是否会增加刷写时的错误率、或者文件数量是否会导致问题。

    我们的测试表明、错误率随着图像大小的显著增加(通过添加大型文件)而增加。 我们的固件 V35的大小为~1.6MB。 图像大小为2.6MB 的器件、以前一直工作的器件也开始生成错误。 但是、大小为1.8MB 的图像显示出不同的行为(请参阅测试1)。 在这里、以前发生故障的所有器件都已成功刷新! 许多小文件的闪存测试未显示错误。 因此、错误可能会受到图像大小或大文件数的影响。 但是、似乎没有直接连接。


    测试1:我们刷写了 mcuImage.bin (284KB)和必要的供应商证书+两个额外的734KB 文件。 整个图像的大小为~1.8MB。
    测试1的结果:所有以前有故障和无故障的器件(A、B、C)成功刷新四次。

    测试2:mcuImage.bin (284KB)和必要的供应商证书+三个额外的734KB 文件。 总图像的大小为~2.5MB
    测试2的结果:所有以前出现故障的设备(B)即使一次也无法成功刷新。
    所有始终工作或偶尔工作的器件(A、C)在3至5个闪存流程中都有错误。

    测试3:mcuImage.bin (284KB)和必要的供应商证书+ 40个1KB 的小型文件。
    图像总大小为~0.42MB。
    测试3的结果:所有器件(A、B、C)已成功刷写。

    所以、我们差不多还在同一个点上。 我们仍在尝试通过 XDS 进行刷写。
    我不认为 CP2105芯片是不可能造成这种情况的、但这对我来说是不可能的。
    闪存过程始终以99%停止。 前几 KB 的内容 我无法想象 CP2105每次在闪存文件结束之前都会受到怎样的影响而产生问题、除非波特率在结束之前更改、等等。 很有意思的一点是、知道 SLImageCreator 在99%时最终会做什么!?
    我可以想象一定数量的字节数会导致软件中出现溢出错误。 这就是为什么它出现在特定尺寸的图像上、而不出现在其他尺寸的图像上。

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

    您好!

    无法使用 JTAG 对 SPI 闪存进行编程、需要使用 UART。 dslite.bat 在我的旧 Uniflash 版本(4.6.0)上支持详细模式。 我不确定它是否支持较新版本。

    如果您已在闪存的 OTP 器件中对供应商目录进行了编程、则可以尝试使用嵌入式编程。 另外、SPI 闪存芯片交换也可能非常有趣、正如我之前建议的那样。

    1月

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

    您好!

    无法提高波特率、因为初始编程期间使用的引导加载程序部分被硬编码为921600bps。

    它们以不同的数字停止在~99%这一事实无关紧要、因为这取决于图像的大小。 它只是说最后一步失败了。

    在最后一步中、创建文件系统需要一些时间、主要是删除 SFLASH 位置。

    查看特定的 Macronix 闪存、通常需要40mSec 来擦除4KB 扇区。

    粗略计算并假设仅满足典型值、而不满足最大值(可能达到210mSec)、那么每个1MB 就可以得到10秒(250个扇区* 40mSec)。

    因此、对于2.5MB 等示例、只需擦除位置(您需要添加实际的写入、加密文件等)即可轻松达到25秒。

    如果将通过 UART 对其进行编程所需的时间相加、则会占用较长的时间。

    话虽如此,实际的方案拟订应该成功,而不是他们所看到的。

    调试引导加载程序阶段很困难、但在这种情况下、尝试使用 CC31xx NWP 器件是有道理的、即使在引导加载程序模式下、该器件也会暴露日志程序。 由于它只有2MB 闪存、因此需要焊接您的8MB 闪存、但它是兼容的、应该可以做到这一点。

    对于 XDS、我们就不使用它、所以我无法对 CP 器件的稳定性和稳健性进行评论。

    此致、

    Shlomi

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

    Shlomi、您好!

    感谢您对​​CC31xx 的想法。 这肯定是一种方法。 但是、我们目前处于生产阶段
    我们需要更快的解决方案。 是否有可能深入了解源代码或有助于我们更好地了解该过程的内容?

    此致、
    Sebastian

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

    Uniflash 的源代码无法共享、用处不大。

    唯一可以帮助的是查看引擎盖下、即引导加载程序中发生了什么情况。

    您能否共享 Uniflash 日志?

    它应该在 C:\Users\下 \.SLImageCreator\temp。

    Shlomi

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

    您好!

    我没有注意到您使用的是供应商证书功能。

    能否说明如果未使用供应商证书会出现什么情况?

    这是一个简单的测试、在该测试中、您可以改用 TI 目录并链接受 TI 目录保护的文件、而不是您的目录。

    我只是想看看它是否相关。

    Shlomi

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

    此外、是否可以测量在非工作案例中返回错误之前的时间?

    我有一个冲它来自哪里,但我需要你测量的时间。

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

    嗨、Shlomi、

    1.使用 TI 虚拟证书进行刷写:

    我们通过使用 TI 虚拟证书对固件进行刷写来测试固件。 始终成功闪烁。  

    为什么闪存有时会因供应商证书而失败? 可能的原因是什么?

    2.闪烁时间:

    我们在不同的定制板上运行了一些测试。 我们观察到具有相同固件的每个电路板上的刷写时间不同。

     具有 TI 虚拟证书的固件的闪存时间。

    固件大小:1596000字节

    Board1:刷写时间- 206 秒(刷写成功)

    Board2:刷写时间- 187 秒 (刷写成功)

    Board3:闪烁时间- 223 秒 (闪烁成功)

    Board4:闪烁时间- 189 秒 (闪烁成功)

     使用 供应商 证书的固件的闪存时间。

    固件大小:1593024 字节

    Board1:刷写时间-  207秒(刷写失败、达到99%)

    Board2:刷写时间- 188秒 (刷写成功)

    Board3:闪烁时间- 209秒 (在99%时闪烁失败)

    Board4:刷写时间- 190秒 (刷写成功)

    此致、

    Swapnil

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

    您好!

    我可以在 ImageCreator 工具中看到超时定义、该定义可能影响特定于供应商的情况。

    是否可以尝试附加的 ImageCreator 可执行文件(从 exe 重命名为 exe)?

    Shlomie2e.ti.com/.../SLImageCreator.xex

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

    您好!

    现在、使用新的 SLIImageCreater.exe 可以成功执行刷写。

    感谢您提供新的.exe 文件。

    此致、

    Swapnil

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

    当然、我很高兴能够提供帮助。

    我将让工具团队将此修复程序推送到主线 Uniflash。

    Shlomi