主题中讨论的其他器件： BOOSTXL-CC3135、 CC31XXEMUBOOST、 CC3135
您好！
我们有一款基于 LPC2929微控制器的现有产品、该产品是使用 Keil uVision 开发的。 该产品一直存在
现在只有2.4GHz Wi-Fi 功能。 由于我们的一个客户最近申请了5GHz Wi-Fi 支持、我们生产了几款
安装了 CC3135MOD 的测试单元、我正在尝试在开始全面生产之前启动并运行这些单元。
我们的器件不使用 NHIB 线路、而是控制模块电源和 nRESET。 NHIB 始终被拉高。
当我打开模块电源并释放 RESET 时、我可以看到它在大约两秒钟后发出 INITCOMPLETE 消息。 该消息是：
[ BA DC CD AB 08 00 14 00 24 04 06 00 00 00 88 88 88 00 00 00 31 00 00 00 00]
状态字节是值得注意的；我将在一分钟内到达它。
现在、如果我请求模块固件版本、我将得到截断的响应：
命令:[78563412708400]
响应：[ BA DC CD AB 70 04 0c 00 24 04 06 00 00 00 00 F9 C7 88 ]
这是正确的响应(操作码0x470 = sl_opcode_device_VERSIONREADSPONSE)、并且长度字段匹配(有效载荷长度0x0c)
但我认为这种响应比应该的短、因为它应该包含多个32位版本字段。 而 VERSIONREAD 是如此
记录在案的即使在器件被锁定时也能正常工作的命令之一。
现在进入状态。 我在 INITCOMPLETE 和 VERSIONREADSPONSE 消息[24 04 04 06]中对 STATUS 字段的读取是：
WLAN conn ：0
丢弃的事件 ：0
设备已锁定 ：1.
配置激活 ：0
配置用户初始化：0
保存 ：1.
启用 API ：0
需要重新启动 ：0
设备已启动 ：0
设备停止 ：1.
设备启动 ：0
因此、该模块声称已(a)锁定、(b)停止、以及(c)禁用 API。 不是我在器件启动时所期望的那样。
我尝试通过 SOP 和 sl_FsCtl()方法回滚到工厂，但两者都不能解决问题。 使用
sl_FsCtl ()似乎暂时释放了锁，但它在下一个响应时又重新恢复了：
sl_FsCtl ()
命令：[ ff ee dd bb 78 56 34 12 4b A4 10 00 00 00 00 00 11 00 80 00 00 00 00 00 00 00 00 00]
响应：[ BA dc CD AB 4b 24 14 00 23 04 06 00 00 00 B3 15 da D7 00 00 31 00 00 00]
WLAN conn ：1.
放弃的事件 ：1.
设备已锁定 ：0 <-已解锁
配置激活 ：0
配置用户初始化：0
保存 ：1.
启用 API ：0
需要重新启动 ：0
设备已启动 ：0
设备停止 ：1.
设备启动 ：0
命令:[ ff ee dd bb 78 56 34 12 70 84 0 ]
响应：[ BA DC CD AB 70 4 c 0 24 4 6 0 0 0 0 F9 C7 da D7]
WLAN conn ：0
丢弃的事件 ：0
设备已锁定 ：1 <-已锁定
配置激活 ：0
配置用户初始化：0
保存 ：1.
启用 API ：0
需要重新启动 ：0
设备已启动 ：0
设备停止 ：1.
设备启动 ：0
我应该指出的是、在这里显示原始消息时、我看到主机驱动程序也是如此。 相反
不过、我很难就该驱动程序进行讨论、因为 sl_Tiny 功能似乎已损坏至错误的程度
编译、而较大的选项几乎不适合我们的器件(因此、我们无法以该形式发货)。 请注意、这是同一个问题
使向[嵌入式]器件写入服务包变得相当困难、因为它需要 sl_Program()、并且我无法获取该器件
服务包锁定时进行 OTA 操作。
相同的主机驱动程序在 PC -> CC31XXEMUBOOST -> BOOSTXL-CC3135上工作、并且行为不同；这些器件不是
它们会正确响应相同的命令。
那么、我的问题是：为什么嵌入式 CC3135MOD 模块被锁定、如何解锁它们？ 对于这种情况、器件应该是如此
在电路板上加载之前已经使用服务包进行了编程、如果是、TI 在发货前不应该这么做？
有关其他要点：如何解决 sl_Tiny 问题？ 我正在使用 simplelink_studio_cc31xx_sdk_1_00_00_05中的主机驱动程序
(sl_driver_version 2.0.1.15)移植到 LPC2929。
此致、
Neil
