[参考译文] CC3235S：在 AP 模式下 index.html 加载正常、但在基站模式下、我得到一个&#39；致命错误#39；

不。  发言太快了。  它工作了一次。  现在返回到致命错误。  我一定会做错事。  如何调试导致 FatalErrorEvent ID 1的原因？

您可以捕获 NWP 日志(请参阅 https://www.ti.com/lit/swru455中 ch.20.1中的说明)。

但确保安装了正确的 SP。

BR、

Kobi

您在 swru455中提到的部分说明我需要使用引脚62、但这是模块下方的接地引脚之一。  这种技术是否适用于 CC3235SMODA？  或者仅适用于具有裸芯片的电路板。

CC3235S 引脚62映射到模块的引脚52 (请参阅数据表)。

BR、

Kobi

感谢您提供与映射相关的帮助-我现在看到了。  但是、在我将焊铁重新焊接之前、我注意到了一些奇怪的事情。  有些人在开发周期中、我安装了服务包 sp_4.7.0.3_3.1.0.5_3.1.0.26.bin

然后、我已多次刷写应用固件、为了节省时间、我每次都不向模块发送服务包。

我刚刚意识到、在配置页面上、构建号下面显示的版本是

4.0.1.1.33.31.3.0.25.3.1.0.31000018

当我再次按下服务包时、我看到了

4.7.0.3.31.3.1.0.5.3.1.26.31100018

这意味着服务包已以某种方式恢复。  怎么会发生这种情况？  当然、一旦我编写了服务包、它会取代原来的服务包？

或者、在我最不期待的情况下、工厂编写的服务包是否仍然"隐藏"等待弹出...

我使用的一批器件的批次代码是9CWCHYC、我认为这意味着2019年3月制造的

遗憾的是、我无法在 Launchpad 上真正测试我的应用、因为它依赖于我的定制板上的许多周围硬件元件来运行、所以我一直在执行大量 Uniflashing 来测试我的代码的每次迭代。

您"推送服务包"了什么？ 更新中？ (即您是否覆盖服务包文件？)

在这种情况下、写入 SP 后、您需要调用 sl_Stop、然后重置 MCU。 在此阶段、器件将处于测试模式。 重置后、将使用新的 image/sp。 如果应用程序工作正常、则 必须提交 OTA 映像(捆绑包)。 否则、在下一次重置时、更新将被恢复。 我建议您参考 OTA 文档以了解详细信息。

除此之外、除非您对器件进行编程、否则 SP 不会被删除/恢复。

BR、

Kobi

我不使用 OTA、我使用 Uniflash 发送服务包和应用程序代码来创建.ucf 文件、然后根据发布的协议将其发送到 UART 引导加载程序。  我的板上有一个适当的 USB 转串行器件、可以操作 SOP 线路并驱动 UART。

到目前为止、为了测试每个开发迭代、我已在 Uniflash 中将"ervicepack"路径留空、假设将其发送一次(通过正确填充该路径)、它将保持不变。

无论我是否将服务包包含在.ucf 文件中、MCU 都会在刷写过程结束时定期复位

(我还不是很聪明，不能考虑 OTA——虽然我很快就要去那个肮脏的池塘——关于证书和签名的整个业务对我来说似乎很可怕：)

因此、您不仅要替换单个(服务包)文件、还要替换整个 UCF 映像。 在这种情况下(即对 UCF 进行编程时)、您将擦除整个闪存并写入新映像。 如果您有时使用的 UCF 不包含服务包-它 肯定会解释问题。

在 OTA 中、我们仅替换特定文件而不擦除其余文件、但 uniflash 用于工厂(初始)编程。