CC3200: CC3200

Hi Daniel,

Disconnect reasons code 109 is described here ( e2e.ti.com/.../2542323 ).
- Do you use own hardware with CC3200? Are you able simulate a issue with CC3200 LanuchPad?
- Are you facing a issue when you switch power policy to always on?
- Are you able simulate a issue with multiple access point types or you have a issue with particular one type?
- How looks RSSI from AP and CC3200 device side?
- How looks RF conditions at test side? Is there many WiFi networks and interferences?
- What version of SDK and Servicepack do you use?

Jan

Hi Jan,

reason_code 109 means missing of consecutive beacons, so you guess that RF signal is not good so that our devices cannot receive beacons?

The answers of your question:
- We use our own hardware system.
- Our devices' power policy is already always on.
- This issue only occurs at customer side and we cannot reproduce it yet.
- RSSI from AP and CC3200 device side seem good.
- RF environment seems not good because there is another AP at the same channel. That is another one we might try to fix to improve RF SNR.
- SDK is 1.3 and Servicepack is 2.10.0.0

Daniel.

Hi Daniel,

>reason_code 109 means missing of consecutive beacons, so you guess that RF signal is not good so that our devices cannot receive beacons?
Yes, it may to be one of reasons. Another option can be some kind of interoperability issue at CC3200 (your design) or at AP side. For example not properly tuned center frequency may cause some issue ( processors.wiki.ti.com/.../CC3100_&_CC3200_Frequency_Tuning ). Proper frequency tuning is important in case of CC3200 is used in wide temperature range.

In case of RSSI is not bad, we can expect that your RF design is not significantly wrong. But my personal tip is a interoperability issue at AP side or wrong RF environment. If you provide here type of AP at customers side (including fw version), TI engineers can check if there is reported a compatibility issue with this particular AP type.

Maybe you can ask your customer, how other WiFi devices work at that exact place. In case of there are issues with other devices (2.4GHz 802.11b/g/n), you can expect issue with CC3200 as well. But it is hard diagnose such kind of issue, in case of you are not be able reproduce it at your desk.

Jan

Hi Jan,

I have another question about this issue.
After disconnection, SimpleLinkGeneralEventHandler() has SL_DEVICE_FATAL_ERROR_EVENT
with EventData.deviceEvent.status = -102 (SL_ERROR_CON_MGMT_STATUS_UNSPECIFIED).
I am sorry that we do not record EventData.deviceEvent.sender.

About SL_ERROR_CON_MGMT_STATUS_UNSPECIFIED, the following link says it is related to deauthentication by the AP\Router.
e2e.ti.com/.../453809
Is CC3200 the same?
The reason is not the same as reason_code 109.

Daniel.

Hi Daniel,

Yes, error codes related to CC3100 are applicable to CC3200 as well.

Jan

Hi Jan,

However, we set SL_SEC_TYPE_OPEN that security problem should not happen, and the Router has no MAC filtering.
Why SL_ERROR_CON_MGMT_STATUS_UNSPECIFIED happens?

Daniel.

Hi Daniel,

Unfortunately I am not able to provide you more information than is stated above.

For more technical you can wait for answer from TI side. But I expect additional information from you side will be required. I think you will need to capture NWP log ( ) and maybe log from WiFi sniffer as well.

Jan

Hi Daniel,

The SL_ERROR_CON_MGMT_STATUS_UNSPECIFIED can happen for various reasons. As Jan suggested, the best way to debug your problem is to use a packet sniffer and/or NWP logger.

Jesu

Hi Jan and Jesu,

Next week we will go to the customer side to get sniffer log.
Will keep you updated.

Daniel.

Hi Jan and Jesu,

I have got the sniffer log, Attached is filtered log.

Why CC3200 change from unicast probe request to broadcast probe request?

Please give me your mail for full sniffer packet.0115_ch1_askTI.7z

Daniel.

Hi Daniel,

You can share the captures with me via private message on E2E.

Jesu

Hi Jesu,

I have already message you the link of sniffer log.
If any problem, do not hasitate to ask me

Daniel

Hi Daniel,

My machine is having difficult time loading the wireshark file. It is too large and contains too much irrelevant information. I suggest you apply filters when packet sniffing.

Jesu

I don't think probe request is related to the error you're referring to.

Jesu said:

I don't think probe request is related to the error you're referring to.

We guess it is the time our device has already disconnected from AP.

But why our device disconnect?

Could you provide NWP logger?

Jesu

Sorry, it is our customer's device, we cannot get NWP logger.

If the disconnect reason codes do not provide enough information I'm afraid you will have to compare the NWP logger to the packet sniffer logs to get a better idea of what is going on.

Jesu