Just got a couple new cores and I can’t get any code that uses the TCPClient working. I’ve tried code that is running on older cores currently, I’ve tried the example TCPClient code in the documentation, all fail to connect.
It is connecting to the cloud services just fine, I can flash code, and publishes work.
Any ideas?
Hi @mwdll
Are you seeing a red flashing LED? Do you get any LED colors other than breathing cyan?
I have been recompiling my Yahoo weather TCPClient code and it is working fine for me.
Memory is tight in the latest release and folks have discovered that code that was just under the limit for RAM in the past is now just over the limit and crashes.
@bko thanks for the reply. Just have breathing cyan through the failed connects. Can’t imagine it is memory since I tested with the very simple example TCPClient code from the documentation.
I also printed all the Network info and it looks good except pings to google IP return 0 packets.
So that google host listed in the example (74.125.224.72) does answer pings for me, so that is a big clue. Just so you know, not all hosts on the net will answer pings and Amazon AWS hosts in particular do not, so that is not always a clue.
Have you tried using Spark.variable or Spark.function to see if they work? If you have a breathing cyan LED, you should be able to get to your core from the cloud with say the controlling LEDs over the 'net example.
I think the simple TCPClient example in the doc needs to be updated to add a Host: www.google.com header to the HTTP GET request since Google uses their hosts to serve many domains (www.google.com, www.gmail.com, etc.).
Has anything changed in your router? Can you get to the internet from other hosts on that router?
I have an older, white spark core running on that router and successfully connecting. When I push the same code to my new black cores, I can’t connect.
I have not tried functions or variables, but publishes work, and I’m successfully flashing the code from the web IDE, so the core is definitely connected to the spark cloud.
The TCPClient connect directly to hosts, not going through the cloud, is that correct?
Thanks
Hi @mwdll
Ok so if publish works, you are on the net. TCPClient goes directly to hosts as you say, but the example may be too simple for Google now, since they have update their service. That host returns a message over HTTP but the search does not work with a Host: header.
When you say it is not connecting, do you mean the TCP connect call fails and you get “connection failed” on the serial console? Or do you see “disconnecting” from the loop() code?
@bko The connection fails.
I’ve been pushing the same code to my old white spark and my new black ones. I’m just plugging them into my macbook, one at a time. So everything is the same except the core. No other hardware is connected.
Here is what I’ve noticed:
The new black ones have to have a factory reset to accept new firmware at least 50 percent of the time. Without a factory reset, they appear to get new firmware but end up running the previous firmware. I’ve never needed to do a factory reset on the white one and have pushed firmware to it probably 100+ times.
I eventually did get the black ones to connect using the TCPClient to connect to Google using the adjusted example code as you suggested – adding host. The black ones cannot seem to handle more complex examples using TCPClient. The white one can.
I did get the black one to ping Google’s IP successfully.
Using the exact same code, the white core will ping local IP addresses on my network(e.g. 10.0.1.109), the black ones never receive packets from local IP pings.
The black one will not successfully connect when using my rest client library. The exact same firmware flashed to the white core works perfectly. I don’t know if this is the memory issue you talked about or something else. It isn’t much code.
All cores work fine for cloud functionality like variables and publishes.
It definitely seems that the black ones, at least the two I have, have some serious quality problems.
HI @mwdll
I don’t know what is going on, but I want to make sure of one thing you are saying: when you say the white silkscreen core does not have the same problems, you mean you are reprogramming it now with the same firmware, right?
It makes a big difference, particularly for the memory issues folks are having, if you have an older core programmed a few days ago or more versus one programmed since about last Friday.
I am assuming you are doing a side by side reprogramming and testing, right?
Maybe we should get @zachary and @dave involved to see if they can think of something I am missing here.
It is certainly possible that you have a couple of bad cores, but my gut tells me that it is a software problem of some kind. Having to do a lot of factory resets is indicative of programs running off the end of something or following pointers into madness etc. When I was screwing up access to the external flash on the core for instance, I would have to do multiple factory resets to get good backup firmware back in to flash memory.
Good discussion here, and I’m really sorry you’re having trouble @mwdll. Huge thanks @bko for the troubleshooting effort.
First, I just updated the TCPClient docs to include the Host header:
http://docs.spark.io/#/firmware/communication-tcpclient
Second, just for clarity, the hardware of the white and black Cores is exactly the same. Nothing has changed.
Third, software-wise, if I’m trying to come up with a difference, the main thing is there were different TI patches available for the CC3000 at the different manufacturing times. Also, TI just released the latest patch, which we have on a branch in the cc3000-patch-programmer repo.
@mwdll Have you used dfu-util to install binaries over a USB cable rather than over the air? It would be helpful to know whether you see this using the exact same command and the exact same binary on the different Cores. When you’re going through the Cloud, it’s possible that there are small differences in the binary. You can use the CLI to do a cloud compile and download the binary, or you can download using the small cloud icon next to your app name in the web IDE.
Also, to eliminate the CC3000 patch difference, I’d encourage you to follow the Quick Deploy instructions but using the latest binary from the ti-patch-1.13.7 branch. Install this patch on all your Cores so we’re sure everything’s the same there. Then try your TCPClient app again and let us know how it goes.