[参考译文] CC3100：引导加载程序模式下的格式返回0x00 0x80

您好！

host_programming.pdf 就是这样吗？

https://software-dl.ti.com/ecs/CC3100SDK/1_3_0/exports/cc3100-sdk/docs/examples/host_programming.pdf

该指南已经过时、我们已将其从较新的 SDK 中删除。 该指南的主要问题是缺少一个步骤、即在串行闪存被擦除后、您应该加载到新文件中-如果您擦除了所有闪存、CC3100无法引导至新的服务接收器、 因为根本没有数据。

在串行闪存被擦除的情况下、器件应从 ROM 代码引导。 也就是说、Uniflash 等工具通常不会在不加载任何内容的情况下擦除串行闪存、因此在这种情况下可能会出现一些意外状态。 为了恢复 CC3100、您需要写入包含文件系统内容的串行闪存、以便 CC3100引导加载程序能够检测有效的串行闪存和文件系统并正常启动。 实际上、0x80事件不应发生-查看引导加载程序、它看起来不像任何地方使用的定义返回代码。 串行闪存擦除命令之后的预期 ACK 是通常的0xCC。

您是否检查了串行闪存以查看它是否被实际擦除？ 如果是、CC3100应从 ROM 引导、然后创建其文件系统。

此外，在将来的参考中，请使用产品线指南的第16.2节，了解有关如何使用 sl_FS* API 从主机设备更新服务接收器的说明。 与您使用的文档相比、此文档具有更多的最新信息。

此致、

Michael

大家好、Michael、是的、这是我使用的 host_programming 指南。  我没有意识到可以在不退出引导加载程序的情况下写入文件系统或编写服务包。

我目前无法查看 SPI 闪存是否被擦除、因此我们使用该总线来至少查看事务。  我可以保证、在尝试格式化之前、闪存_was not _ formatted 并且没有包含服务请求。 当我们组装电路板时、这些器件仍然未通过制造商的编程。

当 CC3100仍处于引导加载程序模式时、我将研究如何使用 sl_FS* API。  您能否提供相关生产线指南的链接？

在 file_operations 示例代码中，这似乎意味着 sl_FS* API 只能在您使用 sl_Start()启动 CC3100并进入有效模式(如 STA 模式)后使用。  由于我无法进入这些模式，我是否能够使用 sl_fs*()？

您好！

很抱歉、未链接生产线指南、此处为 ：www.ti.com/lit/swra658

是的，只有当 sl_Start()返回并且您的 CC3100在有效模式下处于活动状态时，才能执行 sl_FS* API。

假设您的串行闪存为空、首次启动时 CC3100将加载其 ROM 固件并从中启动、从而允许 sl_Start()返回。 从此处开始、您需要执行生产线指南第16.2节中的步骤、以将器件更新为最新的 SP。

现在、您的 CC3100似乎不再响应 sl_Start()、这有点奇怪。 如果闪存被擦除并被格式化、那么它应该启动到 ROM 代码中。 如果不是、那么它应该仍然没有内容、因此应该启动到 ROM 代码中。

您是否有其他电路板或串行闪存器件、您可以尝试这些更新步骤？ 由于 CC3100上没有非易失性存储器、更换串行闪存就足以将其恢复为默认功能。

如果您想确认导致 CC3100器件启动失败的原因、您还可以从器件捕获调试 UART 日志。 请查看编程人员指南第19.1节中的说明 ：www.ti.com/lit/swru368

您可以跳过多路复用指令中的这些日志的第一步-该引脚始终为 CC3100上的 UART 调试启用。

此致、
Michael

谢谢 Michael。  我还没有能够检查 sFlash 的内容、但我认为我已经收集了一些加密的 UART 调试日志。  我希望我已经正确收集了它。

e2e.ti.com/.../cc3100_2D00_debug.zip

此日志包含尝试使用 sl_Start()初始化 CC3100的操作，在此操作中我获得了异步超时。  然后重置到引导加载程序并尝试格式化 sFlash。  我一直等到它稳定成一种在停止日志之前从212和209字节的加密调试数据交换块中退出的模式。

您好！

感谢您提供日志、这些日志可通过我的记录器工具进行解码、我将对其进行分析。

似乎有很多引导加载程序错误、我需要仔细检查和调试、因此我将在下周向大家介绍我的发现

此致、

Michael

大家好、Michael、我有什么最新动态吗？

您好！

仔细查看日志、看起来串行闪存已损坏。 引导时、引导加载程序将尝试读取串行闪存并执行一系列检查、以确保文件系统的有效性。 这些检查在启动过程的早期就在您的设备上失败、因此未加载文件系统、导致启动过程的其余部分失败。 此时、异步错误被抛出到主机。

现在、由于引导加载程序似乎无法使用损坏的串行闪存进行操作、因此您需要使用外部 SPI 编程器擦除该串行闪存、或完全使用空白部分替换该部分。 遗憾的是、通过 Uniflash 或主机编程进行擦除不是一个选项、因为这两个选项都假设引导加载程序可以正确启动。

此致、

Michael

好的。  我将研究如何手动重新格式化 SPI 闪存以恢复电路板。  同时、您可以告诉我有关使用主机编程设置空白部分格式的问题吗？

您好！

如果您可以使用主机连接到 CC3100并执行 sl_Start()，那么接下来您只需按照生产线指南的第16.2节将新的 servicepack 文件编程到 CC3100串行闪存中即可。

请告诉我、这是否似乎不适用于您的设置。

此致、

Michael

Michael、您可能已经失去了这条线程的跟踪记录？ 我不能 sl_Start()，因为格式失败，我们刚刚讨论过。 我正在研究使用外部闪存重新擦除 SPI 闪存。

我对您的问题是有关失败的引导加载程序格式。 如何调试失败的格式？ 格式化失败后转储闪存内容是否有帮助？ 这是否能让您深入了解失败的原因？

您好！

我误解了您之前的帖子、因为您似乎在寻求有关您恢复设备后该怎么办的建议。

至于调试失败格式、由于串行闪存已发生故障、因此我们在调试故障时可以做的事情不多。

如果使用 SPI 闪存编程器重新格式化串行闪存后、您在使用 format 命令后会看到进一步的可重现故障、那么最有用的调试信息是捕获在执行 bad format 命令时打印的 NWP 日志。 串行闪存的内容可能也很有趣、 但是、主要调试信息来自这些 NWP 日志、因为它将在格式化过程的每个步骤中输出调试消息、并且我能够更准确地识别出错误的地方、而不是尝试从损坏的串行闪存中向后工作。

话虽如此、根本没有必要运行 format 命令。 我深入了解了引导加载程序代码、并确认引导加载程序命令的所有格式都确保文件系统和整个串行闪存被擦除和调零。 如果您的串行闪存已为空、则实际上不需要执行该步骤。

正如我在上一篇文章中提到的、一旦您将一个空白串行闪存连接到 CC3100、您只需跳过格式步骤并执行以下步骤、即将 SP 下载到 CC3100。

此致、

Michael

好的。  我正在研究一种手动擦除 SPI 闪存的方法。  但是、我最初上传的 NWP 日志包含尝试在引导加载程序中格式化 SPI 闪存的操作。  您是否能够从 NWP 日志的该部分收集任何内容？

您好！

在 NWP 日志中、记录的主数据似乎包含两个引导加载程序启动序列。 在这两种情况下、由于检测到串行闪存二进制文件损坏、引导在很早的时候就会失败。 在这两种情况下，引导都将结束，并将异步错误返回到主机。

因此、似乎引导加载程序未尝试运行格式化命令、即使已接收到该命令也是如此。

此致、

Michael

这令人困惑。  首先，是的，我尝试使用 sl_Start()初始化器件。  失败后、我确信我复位到引导加载程序中、并在发出 format 命令之前等待接收0x00 0xcc。  发出 format 命令后、引导加载程序会延迟4-5秒、然后返回0x00 0x80。  您是否说引导加载程序本身初始化失败、因为即使返回0x00 0xcc、串行闪存也已损坏？  这似乎不正确。

您好！

在您的第一篇帖子中、您提到了

这是否意味着 sl_Start()在某个时候起作用？

从您收集到的日志中、我到目前为止的观察结果表明格式化过程中出现了错误并导致串行闪存损坏。 是否可能存在中间故障状态、其中引导加载程序仍在运行、但处于不良状态、导致格式失败、这种情况可能会也可能不会发生。 由于我们没有第一个格式命令的日志、而事情发生了、因此我无法肯定是什么导致了串行闪存损坏。

如果在某个时候 sl_Start()正常工作，则可以跳过整个格式化步骤，只需使用常规应用程序 API 将新的 servicepack 文件写入串行闪存。 我建议您在恢复串行闪存后尝试执行此操作。

此致、

Michael

是的、在尝试格式化闪存之前、当闪存在出厂时刚刚被取消编程时、sl_Start()正常工作、我可以在一定程度上在 STA 和收发器模式下使用 CC3100。 有些操作似乎不起作用、我在这个网站上寻求支持、直到我必须更新服务包、然后我不得不等待新的电路板。  (有关示例、请参阅我的其他帖子。)

我们已经对电路板进行了返工、以便能够访问电路板上无法在格式化后初始化 CC3100的串行闪存。  转储闪存时、我们发现它已完全擦除(所有0xffs)。

然后我创建了一个 Gang 映像以手动编程(e2e.ti.com/.../gang_5F00_1.1.14_2D00_2.12.2.8_5F00_1.zip)。  编程后、我们读取确认写入成功、除了 Gang 映像未覆盖的闪存剩余部分(大小不是1MB)。

删除了返工后，我们再次尝试使用 sl_Start()初始化 CC3100，发现它仍然报告异步超时。

我连续多次尝试引导、再次收集了 NWP 日志(e2e.ti.com/.../cc3100_2D00_debug2.zip)。

此外、在对 Gang 映像进行编程之前、我们对 CC3100和格式化串行闪存之间的 SPI 总线上的一些活动进行了跟踪。  下面是一个文本表示、我还将附加图像：

*主器件发送0xab、0x05、0xff、0x05、0xff (从断电状态释放)
*主器件发送0x9f、时钟输出3个字节- 0xc8 0x40 0x14 -闪存器件的 ID (这意味着器件正在响应)
事情会静音500微秒以上、然后会发生以下情况：
*主器件发送0xab、0x5、0xff、0x05、0xff (同样、 再次从断电状态释放)
*主器件发送0x9f、时钟输出3个字节- 0xc8 0x40 0x14 -闪存器件的 ID (就像之前一样)
*主器件发送0x05 (读取状态寄存器)
*主器件时钟从器件输出0x00
*主器件发送0x03、0x00、0x00、0x00
*来自器件的0xff、0xff、0xff、0xff 主时钟
*主器件发送0x05 (读取状态寄存器)
*器件的0x00主时钟
*主器件发送0x03、0x00、0x10、0x00
*来自器件的0xff、0xff、0xff、0xff 主时钟
然后、器件会等待一段时间并执行以下操作：
*主器件发送0x05 (读取状态寄存器)
*器件的0x00主时钟
*主器件再次发送0x03、0x00、0x00、0x00
*主时钟输入0xff、0xff、0xff、0xff、…… 14字节。 不过、它可能更重要、但 Logicport 没有足够大的缓冲区来捕获它之后的内容。

您好！

感谢您执行这些测试并提供新的 NWP 日志。

与之前的日志一样、CC3100似乎检测到文件系统损坏、尽管位于引导加载程序代码的不同区域。 这是一个奇怪的结果、这次我们知道您可以确保通过 SPI 直接将 Gang 映像应用到串行闪存、因此 SPI 应该是良好的。

最不寻常的发现是、在对 SPI 闪存重新编程之前、您看到它实际上已被 CC3100正确擦除。 因此、CC3100首先不应检测到损坏的串行闪存。

您的 CC3100可能已损坏或有其他缺陷。 您是否有另一个可以使用的 CC3100或一个可以使用的 EVM？ 最好确保 CC3100 IC 本身不是错误的原因。

此致、

Michael

大家好、Michael。 是的、我们复制了至少两个 CC3100上的行为、即(在格式化和重新初始化失败后)已使用 Gang 映像对其串行闪存进行编程。

CC3100检测损坏还有哪些其他原因？  我们已验证串行闪存是否可以看到来自 CC3100的请求并在总线上做出响应。

您好！

要找出可能检测到损坏的确切原因、需要通过 NWP 日志进行筛选、并将错误代码与 CC3100 ROM 引导加载程序源代码进行比较。

会发生各种检查、但基本概念是在启动时检查串行闪存内容、例如文件表、关键系统文件等。 如果由于串行闪存读取错误或文件不匹配而在引导期间出现错误、引导加载程序会将串行闪存标记为损坏。

您是否有可用于测试的 CC3100 BoosterPack？ 我想知道您的电路板或串行闪存是否存在某种问题、从而导致明显的损坏。 如果我们能够在 CC3100 BoosterPack EVM 上重现相同的行为、则会极大地缩小问题的潜在根源、并允许我在我的末尾直接对此进行调试

您正在使用的串行闪存器件是否在推荐的已知良好的串行闪存器件列表中？ 该列表可在 CC3100/CC3200串行闪存指南的表8中找到： https://www.ti.com/lit/swra657

此致、

Michael

您好！

浏览串行闪存的数据表、TI 似乎认为它应该兼容。

连接 CC3100MODBoost 并复制该行为将非常有帮助。

此致、

Michael