Some core won`t connect--DNS issues [RESOLVED]

Troubleshooting
1

Need your help guys.
I`m working on a few object project and i have 6 different cores.
for some reason only some of the objects run this code:

 if (client.connect(server, 80)) {
    debug("connected");
    client.print("GET ");
    client.print(url);
    client.print(OBJECTID);
    if (sizeof(args) > 3) {
      client.print(args);
    }
    client.println(" HTTP/1.0");
    // client.println("Connection: close");
    client.print("Host: ");
    client.println(server);
    client.println("Accept: text/html, text/plain");
    client.println();
    result = "connected";
  }  else
  {
    debug("connection failed");
    result = "failed";
  }
  return result;
}

Only some of them are doing the right thing and connect to the server and the others return ā€œconnection failedā€.
Any suggestions?

2

Hmmmā€¦ Letā€™s ping @bko for this.

How about patching all the cores with the CC3000 patch and make sure they are all running the latest version for a fair test?

3

HI @omrigotlieb

I agree with Kenneth that getting the TI CC3000 up to current patch level is a good first step if you havenā€™t done it already.

Can you show how you call this code? For instance, server must a string not an IP address for the Host: line to work.

Do all the cores do GET requests to the same host?

1 Like
4

@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?

I use cli compile and dfu to flash the bin.

5

Hi @mtnscott

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.

6

@bko OK, so I have done firmware reset - holding down reset+mode and then mode until core flashes white. Then reset WiFi settings using spark cli

spark setup wifi

Then I test tinker using IOS and I can toggle D7, but when I flash my code the core wonā€™t connect using

TCPClient.connect(host, port);

I try 10 times and all calls fail. Same code flashed on different core work fine.

Any suggestions?

I have also done deep_update twice, when I do the deep_update I factory reset, setup WiFi credentials, test tinker, put core into DFU mode (flashing amber) and from the cli

spark flash --usb deep_update_2014_06

The spark goes thru its light sequence, and downloads the deep update (flashing magenta) and restarts. So I assume that works ok, still not working on connects.

7

Hi @mtnscott

I am assuming that the router setup and any special routing stuff is all taken care of so that your core can reach the host via TCP. If you can check your router logs, that might bring some clues too.

You could have a hardware problem, but there is more long-shot thing to check. Sometimes the TI "deep update" patch clobbers the MAC address of the TI Wifi chip.

Can you print your MAC address to serial on the non-functional core? There is code here that shows how:

http://docs.spark.io/firmware/#wifi-macaddress

A correct address starts with 0x08 0x00 0x28...

See here for a fix:

8

@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.

9

Here is a test program I wrote for someone else in the forum:

void setup() {
  Serial.begin(9600);
}
void loop() {
  uint32_t ip_addr = 0;
  char hostname[] = "www.google.com";  //your host name here!
  unsigned long tic = millis();
  int16_t retval = gethostbyname(hostname, strlen(hostname), &ip_addr);
  unsigned long toc = millis();
  IPAddress resolvedIP(BYTE_N(ip_addr, 3), BYTE_N(ip_addr, 2), BYTE_N(ip_addr, 1), BYTE_N(ip_addr, 0));
  Serial.println(resolvedIP);
  Serial.println(retval);
  Serial.println(toc-tic);
  delay(5000);
}

If that fails, maybe you could try this alternate DNS library created by @Hootie81

He had trouble with a slow link that the coreā€™s DNS would always timeout on.

10

@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.

1 Like
11

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.

12

@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.

Thanks!

1 Like
13

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

1 Like
14

@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.

15

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ā€¦