-
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).
-
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
acceptfunction, 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. -
:) Yes, but (Tessel seems to have more serious problems right now)[http://us7.campaign-archive1.com/?u=f32fc2fe1a1f2c3463a081e4b&id=1724218942&e=c1b9368332] 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.
-
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.
-
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(onPageRequest).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
-
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:
- returning connect
- 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?
- returning connect
-
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 :(
Gordon
Sacha
DrAzzy
allObjects
user7011-
Post a reply
About
CC3000 initialisation and/or timeout issues
Posted by
@Pat
All, am running the following code - which often works !
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