CC3000 initialisation and/or timeout issues #4731
Replies: 1 comment
-
Posted at 2014-03-25 by @gfwilliams 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). Posted at 2014-03-26 by Pat Will try a different PSU and have installed 1.59, seems better but getting a few new messages ! Posted at 2014-03-26 by @gfwilliams 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 Posted at 2014-03-26 by Sacha Hi Gordon, Very stable WIFI and/or Ethernet connection with a robust IP stack should be a goal. It has also a good part. When there was no problem with WIFI/Ethernet at all, i've never implemented a xBee module ;-). Sacha Posted at 2014-03-26 by @gfwilliams :) 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. Posted at 2014-03-26 by @gfwilliams By the way, W5500 Ethernet seems reliable - so it's not the SPI or HTTP library that's at fault. Posted at 2014-03-26 by DrAzzy
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? Posted at 2014-03-26 by Pat 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 Posted at 2014-03-27 by @gfwilliams @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. Posted at 2014-03-27 by Pat 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 Posted at 2014-03-27 by @gfwilliams So is the Espruino still responsive at that point? or can you not enter commands at all? For now, I'll look into it at some point (maybe next week now) and will see what I can do though... edit: changed timeout Posted at 2014-03-27 by Pat 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 ! Posted at 2014-03-27 by @gfwilliams Ahh, ok - sorry - I thought it was in milliseconds, but it is in seconds. Just use Posted at 2014-03-28 by Pat I figured, could go in the docs. TVM :) Posted at 2014-04-06 by Pat Just wanted to report that this is much better now, but still not 100% .. I am running this code ..
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 Posted at 2014-04-07 by 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. Posted at 2014-04-07 by @gfwilliams 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... Posted at 2014-05-23 by Pat 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 :) Posted at 2014-05-23 by @gfwilliams \o/ Great news! Posted at 2015-01-12 by @allObjects 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.
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? Posted at 2015-01-12 by @allObjects 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:
And this is the console output:
Interesting is that the callback is obviously called multiple times:
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? Posted at 2015-01-12 by @gfwilliams Did you ever have the CC3000 working before? It could well have been a wiring issue. As I recall the initial Posted at 2015-05-31 by user7011 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? Posted at 2015-06-01 by @gfwilliams
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:
|
Beta Was this translation helpful? Give feedback.
-
Posted at 2014-03-25 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
Beta Was this translation helpful? Give feedback.
All reactions