CC3200: CC3200 Wifi Shutoff Debug

Hi Kris,

Reading values from sl_DevGet() will not be much useful at such case. Best way for debugging such issue will be capture NWP log ( see chapter 19 at swru368 ) and capture WLAN communication by WiFi sniffer.

Jan

Hi Jan, thank you for the quick response! I'm happy to do this, but my customer has UART1 pinned out. Can you I re-route the output to UART1 instead?

CORRECTION - UART2 is pinned out on this board

Hi Kris,

I am not sure if NWP log can be mapped to other pins at CC3200. I know that NWP log pin can be re-mapped to some other pins at CC3220 devises, but I am not sure about CC3200. Please wait for answer from TI if there is a option for re-mapping pins at CC3200.

With CC3220 you have options:

• MAP_PinTypeUART(PIN_53, PIN_MODE_5);//GPIO30
• MAP_PinTypeUART(PIN_18, PIN_MODE_3);//GPIO28
• MAP_PinTypeUART(PIN_60, PIN_MODE_3);//GPIO5
• MAP_PinTypeUART(PIN_62, PIN_MODE_1);//GPIO7

Jan

I also don't have the NWP logger muxing info for CC3200 also. It will take couple of days to find the right contact.

I guess you can try the CC220 muxing options.

Does the Amazon Eero router configured on channel 6 also?

Can you control the Eero channel? Can you verify if the conflict happens on other channels?

When the CC3200 stops broadcasting its beacons - is it temporary? (i.e. it will recover after some time? if yes - for how long?) 

Hi Kobi,

No problem. Please let me know the pin muxing information when it is available.

The Amazon Eero routers are a consumer simplified device which do not allow or indicate which channel they are currently using. In fact, they are known the dynamically change them so it is very difficult to say if that is operating on Channel 6 when the issue happens. My guess is that it likely is using Channel 6 in some form, but there is no data to back up that theory.

When it stops broadcasting, it stays off until a sl_stop and sl_start or device reset are performed.

Regards,

Kris

Do you get any async (error) event from the NWP?

What SP are you using?

Hi Kobi,

Thank you for your reply. I have not done anything on the NWP pending information on if it can be used with UART2 / pinout changes. Is this something I can do without streaming the data out?

This is using CC3200SDK v1.5.0 and TIRTOS 2.16.00.08

Regards,

Kris

What version of NWP service pack is installed? (A service pack must be installed).

The information I was asking about is from the host (async events may be received in SimpleLinkGeneralEventHandler,  SimpleLinkFatalErrorEventHandler or SimpleLinkWlanEventHandler). Do you have any way to print logs from the app MCU?

If yes, please print at least the "id" associated to the event received.

If not you, you can set breakpoints in the functions mentioned above and check for error status.

br,

Kobi

Hi Kobi,

If I remember correctly those pin mux settings were also valid for the other CC32xx devices, not just the CC3220. Don't have access to the documentation anymore, but it should be linked internally on the helpful links page. So the pin settings Jan provided should be useable.

Kris - I have some notes about capturing the NWP output that you can reference as you switch the pin muxing

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/954460/cc3220s-launchxl-possible-issue-in-simplelink-4-30-6/3527502#3527502

Basically, if you can see some recognizable plaintext in the UART data stream at whichever alternate pin you use at 921600 baud you'll be able to tell it's working.

Regards,

Michael

Thanks, but i still couldn't verify (in a document) that this works for cc3200.

According to Michael, it is worth to try.

Thank you all. I will go ahead and try to reroute the logger to another UART. I will also collect the NWP version and post that. Please allow me a few days to get this experiment completed and will return with more information.

Follow up question. How does the NWP Service Pack get programmed? Does it come with one from the factory?

Is it possible that even though they are loading the same bin / same setup through Uniflash that they are operating on a different NWP SP, and that is why only some of the devices are having the issue?

Hi Kris,

Programming of Service Pack is done by Uniflash and it is responsibility of user. Service Pack can be updated by OTA as well. It is expected that latest Service Pack is programmed by Uniflash (you need to change Uniflash image settings to do this). If this programming step is not done during initial production programming, this is not good definitely.

CC3200MOD contains some ServicePack version from factory. Version of ServicePack vary on manufacturing date of module and cannot be easily predicted. If you not formatting SPI flash during production by Uniflash, than this factory SP will stay there. But if you format flash and not program ServicePack, device will be used without Service Pack. As first step you need to determine how looks production programming (what ServicePack is programmed if any).

Jan

Thanks Jan! From my discussions with them, I am confident they are only programming the MCU side of the device so the SP is likely whatever came from the factory. I'll make a program to log the different NWP versions for the failing and non-failing units and then have them do an upgrade afterwards.

Hi,

Yes, this sounds like a good plan. Your issue may to be related to old or missing ServicePack definitely.

Jan

Which are the actual parameters in SlVersionFull which indicate the service pack? On the one device from their lot that they shipped me, the NWP version is 2.2.0.1. However, the latest Service Pack download I can find is Version: 1.0.1.15-2.14.0.0.

I am having a strange problem which seems to be with sl_DevGet. The function seemingly returns because it is able to stream out the NWP information afterwards, but it is always triggering a watchdog reset sometimes in the middle of the data stream. I have tried servicing the watchdog before and after the call. It seems like it is causing something to hang somewhere so I can't be certain the 2.2.0.1 is reliable.

Hi,

Because WiFi coprocessor contains multiple cores (NWP, MAC, PHY) from this reason ServicePack number contains multiple numbers. Version 2.2.0.1 is a NWP version from some very old service pack (let say 7 years back). NWP version is a good way how to identify particular ServicePack. At your case is ServicePack extremely old, and this can cause many interoperability issues.

There is no reason for issue (freezing/restarting by WDT) when sl_DevGet() API is used. This issue sounds me like a some implementation issue inside your code.

btw... are you using sl_ API inside asynchronous handlers? Because this is prohibited at CC3200 devices.

Jan

Hi Jan,

Thanks for the information. Here is the complete list for the device I have:

CHIP 67108880
MAC 31.1.2.0.2
PHY 1.0.3.23
NWP 2.2.0.1
ROM 13107
HOST 1.0.0.10

I have resolved the watchdog reset issue. It seems to be a problem with sprintf overrunning the stack when used in that part of the code. I relocated it and no more resets. Really strange problem to debug but not interested in spending anymore time on that!

I'll get this version out to the customer next week to start collecting data on the failing units. I won't do any NWP logging until we have seen if the problem still exists on newer service packs.

Hi,

Yes, this sounds great. I think there is a good chance that your issue will be solved by updating ServicePack.

From you host driver version it seems that your code is based on SDK 1.10, which is very old (Feb 2015). It may to be reasonable to update SDK version as well.

Jan

Good morning. I'm the bearer of bad news today. The client applied the service pack and SDK updates and is still experiencing the failure.

Before upgrade:

CHIP 67108880

MAC 31.1.2.0.2

PHY 1.0.3.23

NWP 2.2.0.1

ROM 13107

HOST 1.0.0.10

After Upgrade:

CHIP 67108880

MAC 31.1.6.0.2

PHY 1.0.3.37

NWP 2.14.0.0

ROM 13107

HOST 1.0.0.10

They are logging outages through a SSID scanner that shows the outages. The problem unit is shown here (highlighted blue). Interestingly, the service pack did seem to make the broadcast strength quite a bit better, but it still eventually resulted in an outage that forced them to reboot the device.

Is this happening using TI launchpad or on a custom board? if it is a custom board, can they replicate it on the launchpad?

do you have more info on the system condition that causes it? (is it only happening in channel 6? only with Eero mesh nearby?)

It is on a custom board. I have previously suggested the TI launchpad idea as I believe that will clearly indicate if it is a device or design problem. It is strange the MCU portion of the device stays functional while the NWP is (seemingly based on data we have) down. I'll bring that up again, but I'm not sure how practical it will be in the environment in the field.

It seems to only happen at a specific field location. That location does have Eero mesh routers, and they are discussing with the location about switching to another access point to see if the issue goes away for additional data points (NOTE the CC3200 is also configured as AP so it is not connected to the Eero). So far the issue seems to only happen on Channel 6. They have a log of an incident on Channel 11, but that device is remote from the logger so it is likely just a signal strength issue. That device did not require a reboot for the SSID to be detected again.

They have quite a few devices at the particular location-somewhere around 10. They have the issue on just a few of them. I'm asking them to pull all of the information posted above to ensure it matches. Other than that, if we take a step back to narrow it down, what can we do to further isolate this issue? I can request they swap a failing device location with a working one in the same field location and see if it follows the device. The Launchpad is a good idea. Any other thoughts?

I will move forward with seeing if we can get the NWP logging via pinout remapping going but will take some time to get implemented.

What is the effect of executing a sl_stop() and sl_start() on the NWP? Is that truly executing a processor reset or just resetting a state machine?

this truly resets the processor.