CCS/CC3100BOOST: TM4C123GH6PM Issue

Hi,

If you were able to run the exact same code before, then the issue you are seeing is most likely with your hardware. You may have damaged something when you were connecting pins during your UART test.

As a debug step, are you able to run radiotool without issues? http://processors.wiki.ti.com/index.php/CC3100_%26_CC3200_Radio_Tool

Radiotool tool will use the CC31XXEMUBOOST to exercise the CC3100. If you can connect and perform radio tests, then your CC3100 hardware is most likely fine. If not, you may want to try using a different CC3100 with your setup to see if you run into the same results.

If radiotool runs fine, then you may want to try running the CC3100 another host device and seeing if that works fine.

Regards,

Michael

I installed RadioTool, and I can start both the Rx and Tx testing without errors, but I'm going to assume there is more I need to test to ensure everything is working properly. Given I know of no way to see the packets being sent / being received, I assume that is likely necessary for this test - could you point me in the right direction?

On another note, I ran the code on my TM4C123GXL board with and without the CC3100. It runs the same both times, appearing to receive an asynchronous timeout error.

I have also tried utilizing the CC3100 on multiple TM4C123GXL boards, so I do not believe it is the underlying hardware either. 

Upon further inspection after a few more runs, the issue has changed - I suspect me running things in Debug mode with a few breakpoints was the cause of the previous timeouts. Now, when the example program getting_started_with_wlan_station  runs the configureSimpleLinkToDefaultState() command, and within, when it runs the command sl_DevGet(SL_DEVICE_GENERAL_CONFIGURATION, &configOpt, &configLen, (_u8 *)(&ver)), a return value of -100 (an error) is returned. 

This error is thrown via the macro VERIFY_NO_ERROR_HANDLING_IN_PROGRESS(), and upon inspection, reveals the code:

if ( g_bDeviceRestartIsRequired == (unsigned char)(!(0))) return (-100); } \
if ( ( (g_SlDeviceStatus & 0x200) == 0x200) != (unsigned char)(!(0))) return (-100);

Note that SL_API_ABORTED is (-100).

Upon further investigation, it seems that g_bDeviceRestartIsRequired is set to true. However, I have no idea how this variable is set, nor why. I certainly am at a loss as to how to fix it.

OK - think I finally hit gold:

As per http://processors.wiki.ti.com/index.php/CC3100_Getting_Started_with_WLAN_Station:

"By default, this application communicates w/ CC3100 over SPI. The SDK has UART-Drivers as well for MSP430F5529LP and Tiva-C platforms. For using the UART interface to communicate w/ CC3100, macro SL_IF_TYPE_UART has to be defined in the application-project's properties."

I don't know what snapped causing the code to stop working at some point in time, but activating this macro did indeed seem to fix part of my issues. Will report back later, but now it seems to be hanging up on making the actual connection to the internet itself, and gets hung p in the following while loop:

while((!IS_CONNECTED(g_Status)) || (!IS_IP_ACQUIRED(g_Status))) { _SlNonOsMainLoopTask(); }

Hi,

If you are using the UART interface instead of the default SPI interface, then that define will indeed be needed. Not sure how it got undefined in your project properties. Without that define set, you will be operating with the wrong interface and as such you won't have any functionality.

As for where you are currently blocked at, that while loop is essentially waiting for that status block of your program to indicate that the device is connected to an AP and has acquired an IP address. If you look at your main.c the SimpleLinkWlanEventHandler() and SimpleLinkNetAppEventHandler() should set that status block.

The connection to the AP is most likely through a sl_WlanConnect() call. As long as your SSID and key provided are correct, then it should connect without issues. I would double-check that first.

Regards,

Michael

The network I am connecting to was listed correctly, and has no password, and such is left blank.

Given the slight fix of SPI to UART, I'm guessing its a matter of certain pins being burned out on the board itself, but certainly could be incorrect.

Hi,

If the sl_Start() command returned successfully with no errors being asserted in the async event handlers, then the interface between the TM4C and the CC3100 should be good. It seems unlikely to me that you could have damaged your devices in such a way that you can perform basic communication between them but not a connection to your Wi-Fi AP. 

Previously, you mentioned that you tried multiple TM4C boards. Did you also try replacing the CC3100 boosterpack to rule out that part being damaged?

Something that will be useful for me to debug your issue would be the NWP logs. This will allow me to see the sequence of events leading up to the wlanconnect and potentially why it is not working for you. If you could follow the instructions here and get those logs for me that would be great:

http://processors.wiki.ti.com/index.php/CC3100_%26_CC3200_Capture_NWP_Logs

Regards,
Michael