TCP client dies

Can someone explains why my core throws CC3000 errors and then blinks RED:

0019198011:<DEBUG> int Spark_Receive(unsigned char*, int) (491):bytes_received 16
0019213129:<DEBUG> int Spark_Receive(unsigned char*, int) (491):bytes_received 2
0019213139:<DEBUG> int Spark_Receive(unsigned char*, int) (491):bytes_received 16
0019234128:<ERROR> hci_event_handler (258):Timeout now 19234128 start 19214128 elapsed 20000 cc3000__event_timeout_ms 20000
0019234141:<ERROR> hci_event_handler (259):Timeout waiting on tSLInformation.usRxEventOpcode 0x0007
0019254152:<ERROR> hci_event_handler (258):Timeout now 19254152 start 19234152 elapsed 20000 cc3000__event_timeout_ms 20000
0019254165:<ERROR> hci_event_handler (259):Timeout waiting on tSLInformation.usRxEventOpcode 0x1010
0019254175:<WARN > bool POST(String, String, bool) (155):[TCP] send failed: status: 2, host: XXX:80
0019254278:<DEBUG> virtual void TCPClient::stop() (193):_sock 8 closesocket
0019274294:<ERROR> hci_event_handler (258):Timeout now 19274294 start 19254294 elapsed 20000 cc3000__event_timeout_ms 20000
0019274307:<ERROR> hci_event_handler (259):Timeout waiting on tSLInformation.usRxEventOpcode 0x1008
0019294318:<ERROR> hci_event_handler (258):Timeout now 19294318 start 19274318 elapsed 20000 cc3000__event_timeout_ms 20000
0019294331:<ERROR> hci_event_handler (259):Timeout waiting on tSLInformation.usRxEventOpcode 0x1003
0019314349:<ERROR> hci_event_handler (258):Timeout now 19314349 start 19294349 elapsed 20000 cc3000__event_timeout_ms 20000
0019314362:<ERROR> hci_event_handler (259):Timeout waiting on tSLInformation.usRxEventOpcode 0x0007
0019334373:<ERROR> hci_event_handler (258):Timeout now 19334373 start 19314373 elapsed 20000 cc3000__event_timeout_ms 20000
0019334386:<ERROR> hci_event_handler (259):Timeout waiting on tSLInformation.usRxEventOpcode 0x1010
0019334396:<WARN > bool POST::Request(String, String, bool) (155):[TCP] send failed: status: 2, host: XXX:80
0019334470:<DEBUG> virtual void TCPClient::stop() (193):_sock 8 closesocket
0019354486:<ERROR> hci_event_handler (258):Timeout now 19354486 start 19334486 elapsed 20000 cc3000__event_timeout_ms 20000
0019354499:<ERROR> hci_event_handler (259):Timeout waiting on tSLInformation.usRxEventOpcode 0x1008
0019374517:<ERROR> hci_event_handler (258):Timeout now 19374517 start 19354517 elapsed 20000 cc3000__event_timeout_ms 20000
0019374530:<ERROR> hci_event_handler (259):Timeout waiting on tSLInformation.usRxEventOpcode 0x0007
0019394541:<ERROR> hci_event_handler (258):Timeout now 19394541 start 19374541 elapsed 20000 cc3000__event_timeout_ms 20000
0019394554:<ERROR> hci_event_handler (259):Timeout waiting on tSLInformation.usRxEventOpcode 0x1010
0019394564:<WARN > bool POST::Request(String, String, bool) (155):[TCP] send failed: status: 2, host: XXX:80
0019394638:<DEBUG> virtual void TCPClient::stop() (193):_sock 8 closesocket
0019394654:<DEBUG> int Spark_Connect() (751):sparkSocket Now =0
0019394661:<DEBUG> int Spark_Disconnect() (822):
0019394667:<DEBUG> int Spark_Disconnect() (831):Close
0019414672:<ERROR> hci_event_handler (258):Timeout now 19414672 start 19394672 elapsed 20000 cc3000__event_timeout_ms 20000
0019414685:<ERROR> hci_event_handler (259):Timeout waiting on tSLInformation.usRxEventOpcode 0x100b
0019414695:<DEBUG> set_socket_active_status (838):Sd=0, Status SOCKET_STATUS_INACTIVE
0019414705:<DEBUG> int Spark_Disconnect() (833):Closed retVal=-1
0019434712:<ERROR> hci_event_handler (258):Timeout now 19434712 start 19414712 elapsed 20000 cc3000__event_timeout_ms 20000
0019434725:<ERROR> hci_event_handler (259):Timeout waiting on tSLInformation.usRxEventOpcode 0x1001
0019434735:<DEBUG> set_socket_active_status (838):Sd=-1, Status SOCKET_STATUS_ACTIVE
0019434745:<DEBUG> int Spark_Connect() (758):socketed sparkSocket=-1
0019434752:<DEBUG> int Internet_Test() (704):socket
0019454758:<ERROR> hci_event_handler (258):Timeout now 19454758 start 19434758 elapsed 20000 cc3000__event_timeout_ms 20000
0019454771:<ERROR> hci_event_handler (259):Timeout waiting on tSLInformation.usRxEventOpcode 0x1001
0019454781:<DEBUG> set_socket_active_status (838):Sd=-1, Status SOCKET_STATUS_ACTIVE
0019454791:<DEBUG> int Internet_Test() (706):socketed testSocket=-1
0019454798:<ERROR> void SPARK_WLAN_Loop() (613):Resetting CC3000 due to 2 failed connect attempts
0019474808:<ERROR> hci_event_handler (258):Timeout now 19474808 start 19454808 elapsed 20000 cc3000__event_timeout_ms 20000
0019474821:<ERROR> hci_event_handler (259):Timeout waiting on tSLInformation.usRxEventOpcode 0x0202
0019494839:<ERROR> hci_event_handler (258):Timeout now 19494839 start 19474839 elapsed 20000 cc3000__event_timeout_ms 20000
0019494852:<ERROR> hci_event_handler (259):Timeout waiting on tSLInformation.usRxEventOpcode 0x0007
0019514863:<ERROR> hci_event_handler (258):Timeout now 19514863 start 19494863 elapsed 20000 cc3000__event_timeout_ms 20000
0019514876:<ERROR> hci_event_handler (259):Timeout waiting on tSLInformation.usRxEventOpcode 0x1010

And sometimes it throws:

0001018963:<ERROR> hci_unsolicited_event_handler (815):isEvent w/Opcode ==0  0x0 4 0x03 0x10 0x09 0x00 0x01 0x00 0x00 0x00 0x01
0001018969:<ERROR> hci_unsolicited_event_handler (815):isEvent w/Opcode ==0  0x0 4 0x03 0x10 0x09 0x00 0x01 0x00 0x00 0x00 0xff
0001018982:<ERROR> hci_unsolicited_event_handler (815):isEvent w/Opcode ==0  0x0 4 0x03 0x10 0x09 0x00 0x01 0x00 0x00 0x00 0x03
0001018987:<ERROR> hci_unsolicited_event_handler (815):isEvent w/Opcode ==0  0x0 4 0x03 0x10 0x09 0x00 0x01 0x00 0x00 0x00 0xff
0001018993:<ERROR> hci_unsolicited_event_handler (815):isEvent w/Opcode ==0  0x0 4 0x03 0x10 0x09 0x00 0x01 0x00 0x00 0x00 0x02
0001018999:<ERROR> hci_unsolicited_event_handler (815):isEvent w/Opcode ==0  0x0 4 0x03 0x10 0x09 0x00 0x01 0x00 0x00 0x00 0xff

The first one looks like you ran out of sockets on the CC3000. There are only seven sockets available and is looks like the one reserved for the Spark cloud connection died after your HTTP POST request. Things continue to go badly and the firmware decides to reset the CC3000 to recover.

Are you checking all the return values from the TCPclient calls in your code? This could help you figure out what is going wrong.

2 Likes

I am using following code to send data:

bool POST(String controller, String post_data)
{
    int i = 0;
    int code = 0;
    boolean inStatus = false;
    char statusCode[4];
    
    if(status && client.connect(host, port))
    {
        client.print("POST /YYY");
        client.println("/ HTTP/1.1");
        client.println("Host: XXX");
        client.println("User-Agent: XXX");
        client.println("Connection: close");
        client.println("Content-Type: application/x-www-form-urlencoded");
        client.print("Content-Length: ");
        client.print(post_data.length());
        client.print("\n\n");
 
        client.write((uint8_t*)post_data.c_str(), post_data.length());

        // Flush
        client.flush();

        // Read response
        while(client.connected()){
            if(client.available()){
                char c = client.read();
                if(c == ' ' && !inStatus){
                    inStatus = true;
                }

                if(inStatus && i < 3 && c != ' '){
                    statusCode[i] = c;
                    i++;
                }

                if(i == 3){
                    statusCode[i] = '\0';
                    code = atoi(statusCode);
                }
            }
        }
    }
    
    // Stop it
    client.stop();
    
    return code;
}

OK I can see what you are doing here. Your while(client.connected()) loop has the potential to block the cloud connection. Do you have the cloud turned off? I would add a timeout or counter to exit the while() loop after a few seconds or a some number of iterations for safety.

I would bet that if you did

int retval = client.write((uint8_t*)post_data.c_str(), post_data.length());
if (retval<=0) {
  //report error etc.
}

it would report something.

How many red flashes to you get? You should see SOS N-flashes SOS N-flashes where N tells you the error type.

1 Like

I added delay(200) before while(client.connected()) but still after a while it dies with same error.

Alright I had a chance to go deeper. I monitored how spark acts and I found a funny things.

I compiled with DEBUG_BUILD flag and using debug_output_ function to get debug information. Also I’ve tried to play with MAX_SEC_WAIT_CONNECT in config.h but still no luck. Spark got cc3000__event_timeout_ms errors and after it dies and throw red led (code 1).

When I checked Apache logs I found weird characters like: ^M^B or ^M or ^M<80>^A^H, data was corrupted (data was merged other POST requests) also found that TCP client sends debug info ("^Mtop() (193):") to target server. I assume that function which ends with “top” and on line 193 could be Cleint.stop() ?

From apache error log: request failed: error reading the headers

Is it possible that there could be some bugs in spark_9 or earlier version?
Can DEBUG_BUILD affect TCPClient operations?
Is there any chance that SYSTEM_MODE is affected any other way?

have you tried a 200ms delay before the stop is called? i notice that i have it in my code for some reason

Have you tried sending a pre-formatted data string, this one below may be doing something strange. if the preformatted string works then you can start looking at this string.

client.write((uint8_t*)post_data.c_str(), post_data.length());

Yes I have tried to add delays to different places, but still no affect. Also I have tried to use Spark REST Client which also does not work as expected.

Whats the expected/avg/max size of post_data.length()

can you share that bit of code too?

Please see my code from here: http://pastebin.com/yDLxacbf
And result was:

0000004262:<DEBUG> int Spark_Connect() (751):sparkSocket Now =-1
0000004268:<DEBUG> int Spark_Disconnect() (822):
0000004274:<DEBUG> set_socket_active_status (838):Sd=0, Status SOCKET_STATUS_ACTIVE
0000004283:<DEBUG> int Spark_Connect() (758):socketed sparkSocket=0
0000004299:<DEBUG> int Spark_Connect() (812):connect
0000004422:<DEBUG> int Spark_Connect() (814):connected connect=0
0000004540:<DEBUG> int Spark_Receive(unsigned char*, int) (491):bytes_received 40
0000004810:<DEBUG> int Spark_Receive(unsigned char*, int) (491):bytes_received 384
0000005188:<DEBUG> set_socket_active_status (838):Sd=1, Status SOCKET_STATUS_ACTIVE
0000005198:<DEBUG> set_socket_active_status (838):Sd=1, Status SOCKET_STATUS_INACTIVE
0000005219:<LOG  > int POST(String, String) (126):[TCP] Try to send: hello=true
0000005233:<DEBUG> set_socket_active_status (838):Sd=1, Status SOCKET_STATUS_ACTIVE
0000005242:<DEBUG> virtual int TCPClient::connect(IPAddress, uint16_t) (72):socket=1
0000005251:<DEBUG> virtual int TCPClient::connect(IPAddress, uint16_t) (90):_sock 1 connect
0000005298:<DEBUG> virtual int TCPClient::connect(IPAddress, uint16_t) (92):_sock 1 connected=1
0000019270:<ERROR> hci_unsolicited_event_handler (815):isEvent w/Opcode ==0  0x04 0x03 0x10 0x09 0x00 0x01 0x00 0x00 0x00 0x01
0000019275:<ERROR> hci_unsolicited_event_handler (815):isEvent w/Opcode ==0  0x04 0x03 0x10 0x09 0x00 0x01 0x00 0x00 0x00 0xff
0000019288:<ERROR> hci_unsolicited_event_handler (815):isEvent w/Opcode ==0  0x04 0x03 0x10 0x09 0x00 0x01 0x00 0x00 0x00 0x01
0000019294:<ERROR> hci_unsolicited_event_handler (815):isEvent w/Opcode ==0  0x04 0x03 0x10 0x09 0x00 0x01 0x00 0x00 0x00 0xff
0000019300:<ERROR> hci_unsolicited_event_handler (815):isEvent w/Opcode ==0  0x04 0x03 0x10 0x09 0x00 0x01 0x00 0x00 0x00 0x01
0000019305:<ERROR> hci_unsolicited_event_handler (815):isEvent w/Opcode ==0  0x04 0x03 0x10 0x09 0x00 0x01 0x00 0x00 0x00 0xff
0000019318:<ERROR> hci_unsolicited_event_handler (815):isEvent w/Opcode ==0  0x04 0x03 0x10 0x09 0x00 0x01 0x00 0x00 0x00 0xff

Custom apache log:

x.x.x.x [10/Sep/2014:19:37:17 +0300] DUR: 0 REQ: "-" STS: 408 BYT: - REF: "-" AGT: "-" DEV: "-"

And fun part, when I’ll change for loop to:

for(int x = 0; x <= 500; x++)

then it works, this counter imitate to calculate “current sensor” value.

Hi @markopraakli

Very strange that the for() loop changes the behavior so much.

I am grasping at straws here but does anything change if you do this:

       data += "&sum=";                        
       data += String(sum, (unsigned char)10);

There have also been problems in the past where turning on debug mode prints so much debug info that the TI CC3000 driver misses messages and get confused.

Im still learning C++ but I’m an extra set of eyes looking over your code so please excuse me if what I’m saying is completely wrong…

A couple of things, you have on line 141 “/n/n” should this be “/r/n” to indicate the end of headers or “/r/n/r/n”

there is no client.flush() before calling stop so the receive buffer may fill up giving red SOS

but i I think the bug is in between lines145 and 179 , we don’t see the 2nd thing you log.

while client.connected is going to always be true if the server is still waiting for more headers maybe?? till you timeout the spark connection. try adding a timeout there to break the loop if it doesn’t disconnect itself, and maybe a timeout while waiting for receive data if it gets none

also if your using c_str() that will append a null terminator at the end of the string? do you need to add 1 to post_data.length() ??

Thanks for your replies. I replaced /n/n to /r/n and added flush before stop but still nothing. Does anyone have a chance to test it itself? My core dies near to 24h and flashing red. One thing what I noticed is that first client.connect() not work, others will do. Does client.connect need some delay after wifi and cloud connection?

HI @markopraakli

It would be a big clue if we knew how many red flashes you are getting. The codes are doc here and are generally SOS, N-flashes, SOS, N-flashes where N tells you what went wrong.

As I mentioned earlier I got SOS 1

Hi,
I think I’m on to something. I suffer from the same bug. My app calls periodically openweather.org to get a json string.
after some digging I came, to the unfundamented, conclusion that the spark does not read the CC3000 fast enough, something like that…, I get also timeouts and they and up in a reset of the CC3000. (All logged as DEBUG or ERROR msg)
So I speeded up reading by calling read(buf,32), in stead of read(). This seems to be less unreliable…

to be continued,

30 minutes later:
Sorry it did not help, after a short period of improved performance it’s now worse…
Is there anybody with a stable working TCP client app?? I busted my 00 of this week and still nothing.

Marcus

I played around heaps with it last week, and managed to get 100’s KB reliably over and over again… i think its to do with reading all the returned data. it seems to come in then stop then come in then stop… try this with something like an image file and you should see what i mean. note the timeout after the reading stops. there is probably a better way to do this, by reading the content length in the header


    Serial.print("Connecting...");
    if (client.connect(server, 80)) {
        Serial.print(" Connected OK");
        client.print("GET ");
        client.print(url);
        client.println(" HTTP/1.0");
        client.print("Host: ");
        client.println(serverName);
        client.println("Accept: text/html");
        client.println("Accept-Charset: utf-8");
        client.println("Keep-Alive: 300");
        client.println("Connection: keep-alive");
        client.println();
        Serial.println(" Sent GET request, Awaiting resopnse");

        unsigned int count = 0;
        unsigned long lastTime = millis();
                while( client.available()==0 && millis()-lastTime<3000) { //ten second timeout
          }  //do nothing
        lastTime = millis();
        unsigned long lastdata = millis();
        while ( client.available() || (millis()-lastdata < 3000)) {  //ten seconds
          if (client.available()) {
              char c = client.read();  //flush data
            Serial.print(c);
            lastdata = millis();
            count++;
          }
        }
        client.flush();  //for safety

        //client.flush();
        delay(400);
        client.stop();
        Serial.println();
        Serial.print("Done, Total bytes: ");
        Serial.println(count);
    
     }
    else {
        client.flush();
        client.stop();
        Serial.println("Could not connect");
    }
delay(10000);
}

Hi,

thanks for your code, it looks similar to mine, I just implemented yours in a new app and it wanted to work, hard faults again.

Does it work fine in your spark?

(This reminds me of an compiler we used from Motorola back in the 80ties for a 6502 micro, micro indeed!, Compile 3 times, and one of them delivers working code…).
In my opinion we have a serious problem with the CC3000 code.

Here’s screen dump of the debug output from a little test sketch I build based on your code:

millis http test
0 connecting …
1073 connected
15788 wait for data
15788 0000021355: void HardFault_Handler() (88):
15788 HardFault
15788

15788 !

millis http test
0 connecting …
1064 connected
1282 wait for data
0 0 bytes received
Done, Total bytes: 0011289 connecting …
12529 connected
27654 wai27654 0000033159: hci_unsolicited_event_handler (815):
27654 isEvent w/Opcode ==0 0x04 0x03 0x10 0x09 0x00 0x01 0x00 0x00 0x00 0x01
27654

27655 0000033160: hci_unsolicited_event_handler (815):
27655 isEvent w/Opcode ==0 0x04 0x03 0x10 0x09 0x00 0x01 0x00 0x0 for data
23375 128 bytes received{“coord”:{“lon”:15.53,“lat”:56.69},“sys”:{“type”:3,“id”:5396,“message”:0.0183,“country”:“Sweden”,“sunrise”:1414216374,“sunset”:1414251055},“weather”:[{“id”:300,“main”:“Drizzle”,“description”:“light intensity drizzle”,“icon”:“09d”},{“id”:500,“main”:“Rain”,“description”:“light rain”,“icon”:“10d”}],“base”:“cmc stations”,“main”:{“temp”:282.77,“pressure”:1018,“humidity”:87,“temp_min”:282.15,“temp_max”:283.45},“wind”:{“speed”:7.2,“deg”:190},“rain”:{“3h”:0.5},“clouds”:{“all”:75},“dt”:1414236721,“id”:2716281,“name”:“Emmaboda”,“cod”:200}

Done, Total bytes: 5352004531337 connecting …
32421 connected
32644 wait for data
28415 128 bytes received{“coord”:{“lon”:15.53,“lat”:56.69},“sys”:{“type”:3,“id”:5396,“message”:0.0183,“country”:“Sweden”,“sunrise”:1414216374,“sunset”:1414251055},“weather”:[{“id”:300,“main”:“Drizzle”,“description”:“light intensity drizzle”,“icon”:“09d”},{“id”:500,“main”:“Rain”,“description”:“light rain”,“icon”:“10d”}],“base”:“cmc stations”,“main”:{“temp”:282.77,“pressure”:1018,“humidity”:87,“temp_min”:282.15,“temp_max”:283.45},“wind”:{“speed”:7.2,“deg”:190},“rain”:{“3h”:0.5},“clouds”:{“all”:75},“dt”:1414236721,“id”:2716281,“name”:“Emmaboda”,“cod”:200}

Done, Total bytes: 5352515441342 connecting …
42416 connected
57334 wait for data
57334 0000062839: void HardFault_Handler() (88):
57334 HardFault
57334

This is totally unpredictable behaviour. I give a break for now. So no weather information in my machine, sniff.

This the code:
*#include “spark_wiring_usartserial.h”
*#include “spark_wiring_tcpclient.h"
TCPClient client;
byte server[] = {144, 76, 102, 166};
void logit(){
Serial1.println();
}
void logit(const char * text) {
static unsigned long time = millis();
int t = (int)(millis()-time);
Serial1.print(t);
Serial1.print(”\t");
Serial1.println(text);
}
void logit(int ii) {
static unsigned long time = millis();
int t = (int)(millis()-time);
Serial1.print(t);
Serial1.print("\t");
Serial1.println(ii);
}
void logit(int ii, const char * text) {
static unsigned long time = millis();
int t = (int)(millis()-time);
Serial1.print(t);
Serial1.print("\t");
Serial1.print(ii);
Serial1.print(text);
}
void logit(const char * text,int ii) {
static unsigned long time = millis();
int t = (int)(millis()-time);
Serial1.print(text);
Serial1.print("\t");
Serial1.print(ii);
Serial1.print(t);
}
//debug output sometimes barge in in the middle of intended prints.
void debug_output_(const char *p) {
static boolean once = false;
if (!once) {
once = true;
Serial1.begin(115200);
}
logit§;

}
void setup() {
Serial1.begin(115200);
Serial1.println("\n\nmillis http test");
}
int cnt = 0;
void doit() {
logit(“connecting …”);
if (client.connect(server, 80)) {
delay(1001); // this waits and forces spark wlan loop to be called…
logit(“connected”);
client.println(“GET /data/2.5/weather?q=Broakulla,Sweden”);
client.println(“Host: api.openweathermap.org”);
client.println(“Content-Length: 0”);
client.println();
cnt = 0;
unsigned int count = 0;
unsigned long lastTime = millis();
logit(“wait for data”);
int nb;
while ((nb=client.available()) == 0 && millis() - lastTime < 3000) { //ten second timeout
// SPARK_WLAN_Loop(); //added this to give CC3000 some attention
} //do nothing
logit(nb," bytes received");
lastTime = millis();
unsigned long lastdata = millis();
while (client.available() || (millis() - lastdata < 3000)) { //three seconds
// SPARK_WLAN_Loop();
if (client.available()) {
char c = client.read(); //flush data
Serial1.print©;
lastdata = millis();
count++;
}
}
client.flush(); //for safety
//client.flush();
delay(400);
client.stop();
logit("\nDone, Total bytes: ",count);
count=0;
} else {
client.flush();
client.stop();
logit(“Could not connect”);
}
}
void loop() {
static int update_cnt = millis() + 10000;
if (millis() - update_cnt > 10000) {
update_cnt = millis();
doit();
}

If anyone has a solution, let us know! I can’t afford the time to debug the CC3000 libraries.

Marcus

Hi @marcus

A few quick points:

  • Since the USARTs have circular buffers that use interrupts to handle data movement, sometimes having too much serial debug data makes the TI CC3000 timeout even more. You could try to limit the amount of stuff you dump.

  • The Openweathermap API page says to not do what you are doing: using the resolved IP address instead of the host name api.openweathermap.org and indeed when I look up by name, I get a different IP address.

  • I have a RSS feed reader for Yahoo weather that uses TCPClient and it works just fine. It is like your code above and runs 24/7 for me. I have been hesitant to post the code since their terms of service indicate that you have credit Yahoo for the data.

  • You should never have to include and spark_wiring_* headers directly. If you need them, use application.h (soon to be renamed spark.h I am told).

  • You could try the user-contributed HTTP library available in the web IDE libraries section or on github.

2 Likes

Hi @bko,

Thanks for the help, here my answers,

  • I am aware of the circular buffers, the mess on screen is absolutely unimportant. That heavy debugging confuses the CC3000, is news, but with out DEBUG defined I log almost nothing. And the results are less than perfect…
  • De openweather api was approached through host look up, but that did not work, a bug in my double set up of access points ;( , that’s fixed, so I can get back to look up by host name. Hardcoded IP numbers are not my favored eider, but it was a work around, and off course we won’t use this in production code…
  • I also tried the example from the IDE, the one where unicorn is looked up by the app. The data returned by google, if any, was truncated at 100 bytes, by me, so no there was no heavy usage of the USART. Unless the care I took not to overload things it also worked badly, I’ll give it a go again soon.
  • About including headers, afaik there is no documentation available on how to use and setup your environment, so one wonders around the code and finds a way to work with it :wink:
  • I will have a look at the HTTP lib’s, thanks for the hint.

But still, I worry about the stability of the communication between the core and the cc3000. I will give it another shot, and let you know my findings.

regards,

Marcus