Other Parts Discussed in Thread: BOOSTXL-CC3135, CC31XXEMUBOOST, CC3135
Hello,
We have an existing product based on an LPC2929 microcontroller which has been developed using Keil uVision. That product has until
now only had 2.4GHz Wi-Fi capability. As one of our customers has recently requested 5GHz Wi-Fi support we have produced a couple of
test units with the CC3135MOD installed, and I am attempting to get those units up and running before full production commences.
Our device does not utilise the nHIB line, rather it controls module power and nRESET. nHIB is pulled high at all times.
When I power on the module and release reset I can see it emit the INITCOMPLETE message about two seconds later. That message is:
[ ba dc cd ab 08 00 14 00 24 04 04 06 00 00 00 00 88 88 88 88 00 00 00 31 00 00 00 00 ]
The status bytes are worrysome; I'll get to that in a minute.
Now if I request the module firmware version I get back a truncated response:
command : [ 78 56 34 12 70 84 00 00 ]
response: [ ba dc cd ab 70 04 0c 00 24 04 04 06 00 00 00 00 f9 c7 88 88 ]
This is the correct response (opcode 0x470 = SL_OPCODE_DEVICE_VERSIONREADRESPONSE) and the length field matches (payload length 0x0c)
but I believe this response is shorter than it should be as it should contain multiple 32 bit version fields. And VERSIONREAD is
one of the commands that is documented to work even when the device is locked.
Now to the status. My reading of the status field in both the INITCOMPLETE and VERSIONREADRESPONSE messages [24 04 04 06] is:
wlan conn : 0
dropped events : 0
device locked : 1
provisioning active : 0
provisioning user init : 0
preservation : 1
api enabled : 0
restart required : 0
device started : 0
device stopping : 1
device starting : 0
so the module is claiming to be (a) locked, (b) stopping, and (c) API disabled. Not what I would expect at device start.
I have tried to roll back to factory by both the SOP and sl_FsCtl() methods, but neither resolves the problem. Using
sl_FsCtl() does appear to release the lock momentarily, but it is back again on the next response:
sl_FsCtl()
command : [ ff ee dd bb 78 56 34 12 4b a4 10 00 00 00 00 00 00 11 00 80 00 00 00 00 00 00 00 00 ]
response: [ ba dc cd ab 4b 24 14 00 23 04 04 06 00 00 00 00 b3 15 da d7 00 00 00 31 00 00 00 00 ]
wlan conn : 1
dropped events : 1
device locked : 0 <-- UNLOCKED
provisioning active : 0
provisioning user init : 0
preservation : 1
api enabled : 0
restart required : 0
device started : 0
device stopping : 1
device starting : 0
command : [ ff ee dd bb 78 56 34 12 70 84 0 0 ]
response: [ ba dc cd ab 70 4 c 0 24 4 4 6 0 0 0 0 f9 c7 da d7 ]
wlan conn : 0
dropped events : 0
device locked : 1 <-- LOCKED
provisioning active : 0
provisioning user init : 0
preservation : 1
api enabled : 0
restart required : 0
device started : 0
device stopping : 1
device starting : 0
I should point out that while I am showing the raw messages here, I am seeing the same thing from the host driver. It is rather
difficult for me to talk in terms of that driver though as the SL_TINY functionality appears to be broken to the point of not
compiling, and the larger options barely fit in our device (so close we cannot ship in that form). Note that this same issue
makes writing a service pack to the [embedded] device rather difficult as it requires sl_Program(), and I cannot get the device
to OTA a service pack while it is locked.
The same host driver works on a PC -> CC31XXEMUBOOST -> BOOSTXL-CC3135, and the behaviour is different; those devices are not
locked, and they respond to the same commands correctly.
So my question is: why are the embedded CC3135MOD modules locked, and how do I unlock them? For that matter, should the devices
have been programmed with the service pack before loading on the board, and if so is that not something TI should do prior to shipment?
For extra points: how do I resolve the SL_TINY problem? I am using the host driver from simplelink_studio_cc31xx_sdk_1_00_00_05
(SL_DRIVER_VERSION 2.0.1.15) ported to the LPC2929.
Regards,
Neil
