CC3000 initialisation and/or timeout issues

Posted on
  • All, am running the following code - which often works !

    function onPageRequest(req, res) {
      res.writeHead(200, {'Content-Type': 'text/html'});
      res.write('<html><body>');
      res.write('<p>Button is '+(BTN.read()?'on':'off')+'</p>');
      res.write('<p>Turn LED1 <a href="/on1">on</a> or <a href="/off1">off</a></p>');
      res.write('<p>Turn LED3 <a href="/on2">on</a> or <a href="/off2">off</a></p>');
      res.end('</body></html>');
      if (req.url=="/on1") digitalWrite(LED1, 1);
      if (req.url=="/off1") digitalWrite(LED1, 0);
      if (req.url=="/on2") digitalWrite(LED3, 1);
      if (req.url=="/off2") digitalWrite(LED3, 0);
    }
    
    var wlan = require("CC3000").connect();
    wlan.connect( "mbed", "*********", function (s) { 
      if (s=="dhcp") {
        console.log("My IP is "+wlan.getIP().ip);
        require("http").createServer(onPageReque­st).listen(80);
      }
    });
    

    But it will often also not initialise, or initialise - pick up a nice IP from DHCP and work away for a bit but eventually die with timeout (16384) errors ...

    Is there anything to be done ??

    Pat

  • Hi Pat,

    It's possible this is due to an issue with the internal timer (which sometimes gets horribly confused). I've just released 1v59 with a fix for this and it may solve your problems.

    It is expected that the CC3000 with randomly refuse to respond sometimes and will need power cycling - but it shouldn't just power cycle repeatedly (unless of course there's some hardware (power supply?) issue).

  • Will try a different PSU and have installed 1.59, seems better but getting a few new messages !

  • Did that happen right after? or over the course of a few minutes?

    And it works fine between times?

    CC3000 support has been a nightmare - it seems the CC3000 chip will sometimes just not respond to a request for data, and that will cause TI's drivers to crash. I've re-written big lumps of them in order to remove interrupts completely, add timeouts to everything, and to try and make it recover when the module does lock up - but I don't know what more I can do.

    If you're interested, the 4101 error is when Espruino is calling TI's accept function, and it just never returns (despite the socket being put into non-blocking mode previously). Espruino calls that function in the idle loop, so it gets called quite often. 99.99% of the time it'll be fine, but occasionally the CC3000 just doesn't respond and has to be rebooted.

  • Hi Gordon,

    Very stable WIFI and/or Ethernet connection with a robust IP stack should be a goal.
    Tessel uses the CC3000 too. I'm wonder if they have issues too.

    It has also a good part. When there was no problem with WIFI/Ethernet at all, i've never implemented a xBee module ;-).

    Sacha

  • :) Yes, but (Tessel seems to have more serious problems right now)[http://us7.campaign-archive1.com/?u=f32f­c2fe1a1f2c3463a081e4b&id=1724218942&e=c1­b9368332] so they may not be thinking about WiFi reliability just yet.

    I've talked to the guy who made the CC3000 module for Adafruit, as well as the people who did the EmbeddedAdventures one (they wrote their own driver) and a few people who have tried to use them - nobody has anything good to say about CC3000.

    I'd be more interested in how Spark Core were getting on - but my understanding is that they had direct input from TI to help solve their problems (possibly because they were one of the first high profile users). Despite repeated attempts I haven't got a single reply out of TI though (I guess I'm not important enough), so I'm pretty fed up with the whole situation.

    It is possible that new firmware on the CC30o0 module itself might help (as all the modules seem to ship with out of date firmware) - but really the only way to do that is to try and add a firmware updater inside Espruino.

  • By the way, W5500 Ethernet seems reliable - so it's not the SPI or HTTP library that's at fault.

  • It is possible that new firmware on the CC30o0 module itself might help (as all the modules seem to ship with out of date firmware) - but really the only way to do that is to try and add a firmware updater inside Espruino.

    Oh, hm. I'd definitely like to see if new firmware fixes any of the problems we're having. How bad is the firmware update process?

  • Gordon, happened later on, but kept going. However, a few hours later I looked at the console again and there was another 4101, but the thing had died again.

    I've tried a couple of different CC3000 modules .. both behave the same way (I thought my original must be a dud).

    Have contemplated a firmware update, but it looked a bit of a production. And I'm not even sure how to check the current rev level actually. Can that be done on the Espruino ?

    I've just kicked it off running again and will keep an eye on it this evening.

    I suspect they are just somewhat flakey !

    Pat

  • @DrAzzy: TI provide tools for firmware update, but only for their own boards :)

    Someone's hacked something together for Arduino though, and I have used it with some success: https://github.com/cmagagna/CC3000Patch

    If that fixes the problem I could look at adding an updater module. Hopefully it wouldn't be too hard to expose the extra functions in TI's driver.

    @Pat - I'm afraid there's no way to get the version at the moment. You'd have to use the Arduino sketch linked above...

    Shame about the 4101 - had Espruino totally crashed? If so I'll have to leave it on a debugger and see if I can track down what the issue is. In the mean time, you can use the watchdog which may help out by resetting Espruino in those cases.

  • Thanks. Afraid it is still rather unhappy. A mix of 4101 and 16384s on both of my CC3000 boards. Sometimes recovers, but eventually dies.

    I'll see if I can have a hack with an Arduino. Gulp :(

    Pat

  • So is the Espruino still responsive at that point? or can you not enter commands at all?

    For now, E.enableWatchdog(10) will at least solve the problem of a complete crash.

    I'll look into it at some point (maybe next week now) and will see what I can do though...

    edit: changed timeout

  • No, Espruino is dead then, can't enter commands etc. Full power cycle necessary.

    E.enableWatchdog(1000) given me ERROR: Maximum watchdog timeout exceeded.

    In fact, anything over 26 gives the error. 26 is Ok, 27 is not !

  • Ahh, ok - sorry - I thought it was in milliseconds, but it is in seconds.

    Just use E.enableWatchdog(10)

  • I figured, could go in the docs. TVM :)

  • Just wanted to report that this is much better now, but still not 100% .. I am running this code ..

    E.enableWatchdog(10);
    function onPageRequest(req, res) {
      res.writeHead(200, {'Content-Type': 'text/html'});
      res.write('<html><body>');
      res.write('<p>Button is '+(BTN.read()?'on':'off')+'</p>');
      res.write('<p>Turn LED1 <a href="/on1">on</a> or <a href="/off1">off</a></p>');
      res.write('<p>Turn LED3 <a href="/on2">on</a> or <a href="/off2">off</a></p>');
      res.end('</body></html>');
      if (req.url=="/on1") digitalWrite(LED1, 1);
      if (req.url=="/off1") digitalWrite(LED1, 0);
      if (req.url=="/on2") digitalWrite(LED3, 1);
      if (req.url=="/off2") digitalWrite(LED3, 0);
    }
    
    var wlan = require("CC3000").connect();
    wlan.connect( "mbed", "Syzygy1313!", function (s) { 
      if (s=="dhcp") {
        console.log("My IP is "+wlan.getIP().ip);
        require("http").createServer(onPageReque­st).listen(80);
      }
    });
    

    Which will run for several days without trouble. I no longer see the 16384 or other errors. But I do now see (eventually) ..

    I'm afraid my JavaScript is not up to really understanding how the whole script works, but I assume at some point, wlan.connect got executed again, s was dhcp but all was not well ?

    There has been one other change, in that I swapped out the actual Espruino board. The previous board had the HC05 bluetooth module soldered on. I experienced some really mysterious goings on which may or may not be related, but ...

    From time to time, All of my 2.4GHz wifi (5Ghz Ok) and All of my bluetooth devices (mice, headsets) etc would stop working in my study/workroom. None could connect to relevant APs or hosts. Elsewhere in house, all Ok. I eventually traced this to the Espruino board .. unplugging it from power, would bring everything back to life. First few times, I thought it was just an oddity. But left long enough, that Espruino board would eventually cause the problem. I have absolutely no way of knowing whether it was the CC3000 or HC05 or something else ??

    Beat that !

    Pat

  • Perhaps I spoke too soon. Latest is that after some period, the Esprunio becomes unresponsive and the GUI disconnected. COM port disappears, so have to re-power.

  • Using software that uses CC3000?

    Looks from your previous error like you get the DHCP message, but before Espruino can process it, the CC3000 disconnects! Does that break things though? It looks like Espruino would still be responsive...

  • Just to report that as far as I can see, the CC3000 issues above (and in other threads) seem to be fixed .. I am running 1v64 :)

  • \o/ Great news!

  • Fiddling on my CC3000.... and get the (16384) error... after ten seconds waiting from connect. I do not get a wlan object back. Espruino is still responsive.

    ERROR: Timeout in CC3000 driver (16384)

    Did someone ever try the module's serial debug port.

    I bought the breakout board from lemonfruit... sorry, adafruit. I usually fine what comes out of this atelier. But I'm obviously not the only one where things getting sour...

    I reverted from 1v72 to official 1v71 and it did not help. Could it be that some of the timing challenges are back?

    Should I go for some other module to connect to wifi? ...may be even to cable? What are my alternatives to get to a working LAN connection?

    Is it worth trying older Espruino firmware versions?

  • Did the thing mentioned last in previous post: tried with firmware 1v59 and 1v60,... no success... but did not give up yet, flashed back (to present) 1v71 and run it again: guess what: it made it through! My fruit needed obviously some time to really wake up and get whipped into working mood... ;)

    This is the code I'm using:

    var SSID = "MyNetworkId";
    var WPA2Key = "MyWPA2Key";
    
    var log = function(s,e) {
      console.log(((e) ? "E: " : "-: ") + 
        (Math.round((getTime() * 1000)) / 1000) + ": " + 
        s
      );
    };
    
    log("Connecting to CC3000...");
    var wlan = require("CC3000").connect();
    if (wlan) {
      log("Connecting to wifi access point...");
      wlan.connect( SSID, WPA2Key, function (s) {
        log("Connected with " + s);
        if (s == "dhcp") {
          require("http").get("http://www.pur3.co.­uk/hello.txt", function(res) {
            res.on('data', function(data) {
              log(">" + data);
            });
          });
        }
      });
    } else {
      log("Did not get wlan object / not connected to CC3000.",1);
    }
    

    And this is the console output:

     _____                 _
    |   __|___ ___ ___ _ _|_|___ ___
    |   __|_ -| . |  _| | | |   | . |
    |_____|___|  _|_| |___|_|_|_|___|
              |_| http://espruino.com
     1v71 Copyright 2014 G.Williams
    >echo(0);
    -: 264.257: Connecting to CC3000...
    -: 266.877: Connecting to wifi access point...
    =undefined
    -: 273.336: Connected with connect
    -: 283.457: Connected with dhcp
    -: 284.169: >Hello World!
    > 
    

    Interesting is that the callback is obviously called multiple times:

    1. returning connect
    2. returning dhcp

    Now moving on to receive realtime online departure train info... see the cool thread of @russdx at Is Espruino right for my project?

    ...what a rhetorical question for an Espruino fan... ;) --- I have a very good hammer - you got nails?

  • Did you ever have the CC3000 working before? It could well have been a wiring issue. As I recall the initial ERROR: Timeout in CC3000 driver (16384) message happens if there is no response from the module at all: eg, it's not wired up, is broken, etc.

  • I am having a issue with the CC3000, when I try to require the cc3000 the stops working. I get no error in the console it just disconnects. I am running version 1v79 do I need to do anything else?

  • I get no error in the console it just disconnects

    It just disconnects from USB? Which board do you have, the Pico or the original?

    I just tried the following here on the original board and it works fine for me:

    ````
    var wlan = require("CC3000").connect();
    wlan.connect( "AccessPointName", "WPA2key", function (s) {
    if (s=="dhcp") {

    require("http").get("http://www.pur3.co.­uk/hello.txt", function(res) {
      res.on('data', function(data) {
        console.log(">" + data);
      });
    });
    

    }
    });
    ```

    However when you do the require, the board will stop responding for maybe as much as 10 seconds while the CC3000 initialises (it shouldn't actually disconnect though). It's annoying, but it's just the way TI's driver works :(

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

CC3000 initialisation and/or timeout issues

Posted by Avatar for Pat @Pat

Actions