TCPClient hangs up core

Dear @mohit!

To fix this issue does it mean we have to manually update the firmware? Isn't that something which is coming automatically with i compile something on the webIDE?

Kind regards,
Noten

@mohit, same question from me; when will the firmware be updated so that this can be done over the air?

Hey All!

We’re in the process of reviewing fixes and firmware pull requests and merging them in. Right now you can pull the latest master from all the repos and compile locally, but we’ll probably update the stable ‘compile-server2’ branches of the firmware sometime next week.

Thanks!
David

@Noten @tomas
The Web IDE uses a stable version of the firmware to which the user app is added to. When we roll out changes or updates, they are first made to the master branch on the core-firmware repo. In order for anyone to test latest fixes before they show up on the web IDE, they will need to use the master branch and compile it locally.

You will also need to pull changes from the master branches for core-communication and core-common repos.

We usually push updates to the IDE once in a week or two.

1 Like

@mohit and @Dave
thanx a lot for your quick response. I found the instructions for the manual update to be abit outside my technical comfort zone, but after trying it seems like I managed to get it to work. :smile:

2 Likes

@satishgn, your code works perfectly. Thanks a lot for your help as well!

2 Likes

I seem to be running this issue with the current master of all three repos. My test application.cpp is included at the end of this post. After some amount of time the Core seems to crash. It crashes somewhere between Serial.println(" -- Connected -- "); and the Serial.print(c);, but I don’t know exactly where. That is also assuming there aren’t any cached prints that don’t make it out before crashing. When it crashed the /dev/ttyACM0 serial port i’m reading closes and the Core seems to restart based on the LED, but I never get a serial port again. In my DMESG I get

[25331.384033] usb 2-1.4: new full-speed USB device number 77 using ehci_hcd
[25331.478195] cdc_acm 2-1.4:1.0: This device cannot do calls on its own. It is not a modem.
[25331.478210] cdc_acm 2-1.4:1.0: ttyACM0: USB ACM device
[25678.241534] usb 2-1.4: USB disconnect, device number 77

If I press the RST button, I get the first three lines again and it runs for a similar amount of time.

I also seem to be having general issues with the TCPClient::connect() function. I’ve been getting a high number of failures to connect, in my tests it fails about 50% of the time. Out of 137 attempts to connect, it failed 861 times before crashing. It was in a Cyan Breathing the whole time.

I have the exact same loop() code running on an Arduino with Ethernet shield and I’m currently at 430 attempts and 1 failure.

When I run my much bigger app it crashes much more quickly. After about 4 to 15 attempts.

#application.cpp:

#include "application.h"

TCPClient client;
char server[] = "m2.exosite.com";

const unsigned long interval = 5*1000;  // delay between updates, in milliseconds
unsigned long failCounter = 0;
unsigned long totalFailCounter = 0;
unsigned long totalCounter = 0;

void setup() {
  Serial.begin(115200);
}

void loop() {
  Serial.println(" -- Stats -- ");
  Serial.print("    Attempts: ");
  Serial.println(totalCounter++);
  Serial.print("    Failures: ");
  Serial.println(totalFailCounter);
  if (client.connect(server, 80)) {
  	failCounter = 0;
    Serial.println(" -- Connected -- ");
    
    client.println("GET /timestamp HTTP/1.1");
    client.println("Host: m2.exosite.com");
    client.println("User-Agent: Spark/? Patrick/0");
    client.println("Connection: Close");
    client.println();
    
    while(!client.available());
    
    while(client.available()) {
      char c = client.read();
      Serial.print(c);
    }
    
    Serial.println();
    
    client.stop();
    
    delay(interval);
  } 
  else {
    Serial.println(" -- Connection Failed -- ");
    Serial.print("    Count: ");
    Serial.println(++failCounter);
    totalFailCounter++;
    client.stop();
    delay(500);
  }
}
1 Like

Can someone help a noobie out here? I’m trying to make the TCPServer example work. Can I use puTTY as a client? If so, what is the host name? sorry if this is silly.

Hi @captnkrunch

If your router is setup for DHCP like most home routers, you will likely have to use the IP address of the core instead of name. You can find the IP address on the core with the Network.localIP() method, which you could print on serial or have a Spark variable to get etc. or you could find it in your router’s connection table with your router management software.

I think puTTY will work ok for telnet type stuff.

Hey @captnkrunch,

Did you get things sorted with the TcpServer example?

Thanks!
David

I appreciate the thought and the help. Unfortunately the simple answer is “no.” I can’t get cli nor nodejs to work so I’m buying a serial LCD and will try to discover the IP address that way.

Hi @captnkrunch,

I’m not sure if you’ve tried this yet, but one alternative would be to store the IP address for your core in a Spark.variable. I’ve done this a few times with my apps to more easily find my core locally, here’s some code:

char myIpString[24];
uint8_t gotIP = 0;

void setup()
{
    Spark.variable("ipAddress", myIpString, STRING);
}

void loop()
{
    checkSetIPAddress();
}


void checkSetIPAddress() {
    if (gotIP) {
        return;
    }
    
    IPAddress myIp = Network.localIP();
    sprintf(myIpString, "%d.%d.%d.%d", myIp[0], myIp[1], myIp[2], myIp[3]);
    gotIP = (myIpString != "0.0.0.0");
}

Also please feel free to ping me directly if there is something broken about the spark-cli, I will get to spend some time on it this sprint so I’d like to improve as much as possible while it’s in focus.

Thanks!
David

1 Like

I was able to get cli running. apparently i didn’t appreciate how long it takes to install so I was cutting it off prematurely before. now I’m getting a 404 error when attempting to verify the code you suggested. ah well. I am grateful for the help though.

@dave,

I’ll open up issues in spark-cli for those undone features.

My pull request has been sitting for weeks :smiley:

1 Like

ooops. apparently the 404 was an artifact of firefox and openssl issue. Chrome works fine. Thanks again.

2 Likes

I’ve been traveling for weeks! :slight_smile:

1 Like

Cool, glad it’s working now!

Maybe you guys need to post the status of the :spark: team members on the spark.io/status. haha!

There has been talk of a Spark powered http://harrypotter.wikia.com/wiki/Weasley_Clock