My cores connect to the cloud and can be flashed over the cloud but simple Connection with TCPClient Fails. I cannot connect either to a local Server or a Google one.
They are the black cores.
It seems similar to
but I do not have white cores to check.
The web IDE says, it compiles with v0.2.3.
Any new ideas on this Problem ?
Thanks Michael
Hi @baatsm
White and black cores have identical hardware. The only difference is that the more recently manufactured black cores come from the factory with more recent initial firmware and TI WiFi chip CC3000 firmware revision.
Which TCPClient code are you trying to get working? Can you post your exact code?
Lots of times folks have forgotten that not reading the data out of the receive side of a connection will make the core memory overflow eventually and cause a fault (flashing red LED SOS code).
Some web code seems to need a delay(20); after the final newline is sent for a HTTP GET request for reasons that are not yet understood. This issue has been captured over on github for the team to debug in the future.
it cannot even ping the local router, but it is connected to the cloud.
Thanks
Michael
sample code:
IPAddress broker = { 192,168,101,1 };
byte once = 0;
TCPClient tcp_client;
void setup() {
Serial.begin(57600);
while(!Serial.available());
Serial.print("test tcp 0.001\n\r");
}
void loop() {
if( !once )
{
once = 1;
IPAddress localAddr = Network.localIP();
Serial.print(localAddr);
Serial.print(" on ");
Serial.println(Network.SSID());
Serial.println(Network.subnetMask());
Serial.println(Network.gatewayIP());
Serial.print("isWanReady = ");
Serial.println(WIFI_ON == WiFi.status());
Serial.print("Pinging 5 times: ");
Serial.println(broker);
Serial.println(Network.ping(broker));
Serial.print("connecting to ");
Serial.println(broker);
if( tcp_client.connect(broker, 80))
{
Serial.println("connected to broker ");
}
else
{
Serial.println("failure: TCP ");
}
if( tcp_client.connect("www.google.de", 80))
{
Serial.println("connected to www.google.de ");
}
else
{
Serial.println("failure: TCP ");
}
}
}
I don't think you have the right IP address here. The IPAddress class has assignment methods for both uint8_t and uint32_t and the {192,168,101,1} type could be int instead of uint8_t.
Try this and see if it helps:
IPAddress broker(192,168,101,1);
I’m sorry. But this didn’t change anything.
Do you have a working ping example ?
Thank You very much.
Your example should work for ping. Something seems to wrong with your router or network setup. Please note that some hosts are not ping’able (cores after the latest TI patch, AWS hosts, some routers).
What kind of output do you get from your program on the Serial debug port?
all other Computers on my net can do the ping (Routers ip and www.google.de ) and get a Response. I even tried with two different wlan-routers.
Thanks
Here’s the Output from the USB-Serial:
test tcp 0.001
192.168.101.34 on xxxxx (ssid)
255.255.255.0 (subnet mask)
192.168.101.1 (Gateway/router)
isWanReady = 1
Pinging 5 times: 192.168.101.1
0
connecting to 192.168.101.1
failure: TCP
failure: TCP
One more thing to try--there was a change introduced recently make a long delay in setup() a problem. Try this:
while(!Serial.available()) { SPARK_WLAN_Loop() };
Ahhh, this did the trick. Working as expected now. Now I can go on to my next Goal, connecting to an mqtt-broker.
Thank You very much.
Michael
Glad to hear it! There are several other folks that have done MQTT broker related project–just search the forum here.
Hi @BKO,
In the topic “TCPClient broken? [SOLVED]” I recognized something that might be similar to a problem that I am facing right now with one of my Photon applications: I control that application with some Particle.functions and Particle.variables from a rather basic webpage, using HTTP GET and HTTP POST. After running well for some time, the system begins to react increasingly slow and/or not at all on my HTTP requests. After powering down the whole system and starting up again it behaves similar again: starting well but after some hours not responding or not responding correctly anymore.
For this reason I am thinking that some kind of memory overflow or so might be the problem.
My questions therefor:
This is a six year old thread on the first generation of Particle products, the Spark Core, so essentially nothing here is really relevant today.
It sounds from your description that you are having memory fragmentation problems, where allocating and deallocating memory dynamically at run time is causing the pool of available memory to get more and more broken up. The best way to avoid memory fragmentation problems is to allocate all the memory you need statically at the start of the program and re-use it. String operations in Arduino can be a particular source of this kind of problem and I would look at any use of String objects in your code with a critical eye.
Thank you very much for your quick response.
How do I allocate all memory statically? I have declared and initiated all at the start of the program (before void setup()). Should I do anything else?
What’s perhaps worth mentioning is that I am using quite some retained variables: 6 boolean and 29 integers, of which 7 are arrays.
Apart from those retained variables, my code uses other int’s and booleans and indeed about 40 strings.
Are there any specific string-operations and/or string objects that can cause these kind of problems?
@Jan_dM, all String operations create permanent or temporary memory allocation on the heap. Strings cause the “breakup” on the contiguity of the RAM used in the heap, creating a situation where the largest chunk of heap that can be allocated gets smaller and smaller. When a DeviceOS function tries to allocate memory for temporary use, the largest available chunk may not be large enough and the operation will fail with unwanted consequences, as you may have found out.
The best solution is to avoid Strings altogether and use fixed-size char arrays instead. The well-documented c-string functions can then be used for all string operations including sprintf() and snprintf() for easily creating formatted string content.
Thank you very much; this seems to work fine (until now)!
One final question: in my program I am using a lot of INT-to-String- or char-to-String conversions for no other reason than being able to read those variables as a Particle.variable.
Would you recommend to declare and initialize all those small strings as well at the beginning of the program???
Particle.variable() can also directly register int and double variables.
Or you could put all those small strings into one big string and cut down on your overall variable count.