@bko I found this thread and seem to be having a similar problem. I have several cores, they have all had the cc3000 patch applied. For some reason one of my cores fails to connect when using TCPClient.connect. Same code flashed. - works on the white one, not on the black one. I have done factory reset on the black core, and verified I can use tinker to toggle D7, also the cloud seems to show the core alive and connected. When I flash my code it fails to connect, the Client.connect call returns quickly with a failure. It will attempt to connect 6 times and it always fails.
Same code on the white core will connect the first time.
I can’t figure out what’s going on. @omrigotlieb did you ever figure out what was going on?
A lot of the black silkscreen cores already have the TI CC3000 patch applied but some early ones do not. There has been one weird problem with a very small number of black cores that don’t connect to the TI part at startup under certain conditions but the symptom is a flashing white LED at startup.
I have screwed things up in my code that more than one factory reset was needed to get back to normal operation. I have also had problems where power-cycling (rather than just reseting) was needed to get back to a working state, so you might try that.
You could have a hardware problem in which case the Spark team would help you out I am sure.
@bko it has a valid mac address 0x08 0x00 0x28 0x73 0x38 0x26. The router has assigned 192.168.1.108 to it. I can ping with it (using IP address), I can connect using an IP address, but I can not connect using name.
Something with DNS lookup on this core in my network is wrong. Other cores work fine. I don’t know enough about wireless routers, dns and the such to understand if this is a router problem with this core, or a core problem.
@bko Thanks! But my internet connection is slow all the time, is there differences between the batches of cores where something is different enough to make one work and the other not? I guess I will have to either always use the DNS library or only use it when the connect fails.
Who can weigh in on the hardware differences between the colors of the cores, is there any?
UPDATE: After thinking about this, the above question does not really matter, I will add the DNS service that works and always use it. Thanks for the help and you can close this thread.
There are no hardware difference between the cores of different colors. The only change was the to silkscreen color. All new cores leaving the factory have the latest firmware, but the first time you connect, you can fix that.
You might just be on the hairy edge with your other cores and just not know it.
By calling gethostbyname() yourself instead of depending on TCPClient to call it for you, you can retry until you get a good answer. Otherwise the library from @Hootie81 is a great resource to have, especially for satellite internet.
@bko, The library from @Hootie81 works like a champ. I could have implemented the getHostByName in my code but since it takes time before it returns with the error I don’t think calling it over and over again is what I want.
I will use the library for now. It seems to work much better in my environment. Unfortunately it’s about 2.3K of flash.
I tried so many different things to get my dns working, there was a few threads on the adafruit forums about the same issue on their cc3k breakout board and there is a couple on the TI forum too.
from memory it is a cc3k issue with reading the dns ip from the router, it gets a weird number stuck in it… i couldnt find a solution so the guys on this forum helped me port the gethostbyname (the DNS lookup) for the Ethernet library from arduino.
I still get the odd fail, but that’s just the internet here maxing out at 3kb/s on a really good day!
there is some repeats in the library, it tries 3 times to get the IP, with a 5second delay between each try. you could easily drop that timeout down to a second, maybe less… i think 900ms was the timeout on the cc3k
@Hootie81 So it appears the problem is with the cc3k and could appear on any core. Do we know if taking the ‘bad’ core to another location with a different router will have different behavior? For example I can test a core here at my house, but in the field it could fail? Or have it working in the field but at my house not work.
I would like to avoid giving up 2k of flash just to address the DNS issue with the cc3k.
Trying to remember how i cleared the strange numbers in the cc3k… ill have a look tomorrow, but if you find out the dns ip address saved in the core, then do a google for it… it should come up there is a few people with the issue…