Timeout in CC3000 driver

During testing CC3000 and some other requires, sometimes the board stopped working and I had unplug to get it back to work.
After some testing, this workflow breaks Espruino

• send code to Espruino Board
  
• wait to get IP adress
  
• disconnect from Espruino Board
  

• connect to Espruino Board
  Some secondes later I get the timeout error (4101).
  Next another error comes up, "got '<' expected EOF at line 1 col 2...."
  Version 1v50 and this source

  
  var wlan = require("CC3000").connect();
  var ip;
  wlan.connect( "JUMWARE-LTE", "B73FD193D04293D", function (s) {
  if (s=="dhcp") {
  ip = wlan.getIP().ip;
  console.log("My IP is "+wlan.getIP().ip);
  require("http").createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.write('IP is ' + ip + '<br>');      
    res.end();
  }).listen(80);
  }
  });
  
  

Hmm. Is that always repeatable? I've filed a bug here: https://github.com/espruino/Espruino/issues/224

I had the timeout error once or twice but was never able to reliably reproduce it, which makes it hard to track down.

On my board, this happens always after disconnect/reconnect.
May be I should mention, that I've also connected the display on SPI2 and a DS18B20.
Looks like reading process.env is broken after connecting.
If I disconnect it runs without this problem, at least the 6 hours in my test.

I've just tested and the issue is the Ctrl+C that gets sent on connect. It breaks out of the CC3000's SPI transmit and then causes all kinds of pain.

You can just remove the \x03 from espruino_process.js and it'll fix this. I guess I need to implement some way of clearing the current line without Ctrl-C. Any ideas for key combinations that aren't as brutal as Ctrl-C, but that you'd still expect to clear the line?

In linux, CTRL+u clears left, CTRL+k clears right. CTRL+l (small L) clears the screen (aka clear). Hope this helps.

removed the \x03 and it works.
thanks

@rardunel, thanks! That's perfect. I'll implement u and k, and then the Web IDE can send both of those in order to make sure the line is clear before it sends its command...

I don't suppose you know if there are Ctrl+ shortcuts for echo on/echo off? That'd be really handy too :)

@Gordon sry for the late reply, I don't know how to enable notifications here :P

I don't think you can do that with a shortcut, but when I don't want the output from a script i simply redirect it to /dev/null, eg: compare the output of ls > /dev/null with ls :P

Later addition (edit does not work): the command > /dev/null only suppresses the stdout, but the stderr messages will still be printed.

In windows command prompt you have echo off which is what Espruino does with echo(0). The issue is that just writing echo off echoes characters, so in Windows you prefix a line with @ if you don't want it to echo anything.

I'm after something like that for the Espruino command prompt - so piping stuff to /dev/null doesn't really help ;)

I am just trying to make my plant/soil/light sensor setup more reliable. I pretty much use the CC3000 example code from the code reference page, e.g. I connect every 60 sec, wait to be connected, get some data, then send it to Xively (thx @Gordon).

The problem is I seem to be getting this from time to time:

Complete, disconnecting...
ERROR: Timeout in CC3000 driver (1)
at line 73 col 6
    });
      ^
in function called from system
Execution Interrupted during event processing - clearing all timers and watches.
> 

The problem is not the error itself, it is that all timers and watches get cleared. That means the espruino stands still. I can live well with that code failing from time to time.

I think we had that discussion before - is there a way to keep the system running somehow?

I'll look at this today... To be honest I should make it clear only the timer that caused the problem when there is an error - as you say it causes huge problems if all timers are removed.

It looks like the error occurs during the call to connect - I hadn't come across that one before... I guess it could still attempt to power cycle the CC3000 in that case.

Yes, I just realize the console log I posted might cause a misunderstanding. I am logging the disconnecting.... and then it would start connecting again 60 secs later and throws the error. So it might really be an issue in connect().

Thx for looking into this.

I posted up somewhere else, but that should be fixed now. connect still throws an error if it fails, but it'll only cancel the one interval - so you can easily work around it.

When an interval gets forcibly cleared like that, how can one detect that and react appropriately?

When an interval gets forcibly cleared like that, how can one detect that and react appropriately?

Good point. There's not an easy way right now until exceptions get implemented - however the best bet at the moment is something like:

setInterval(function() {
 ...
 wifiSuccess = false;
 setTimeout(function() {
  // initialise WLAN
  wifiSuccess = true;
 }, 10);
 setTimeout(function() {
  if (!wifiSuccess) { ... }
 }, 1000);
, 60000);

If there's an error in wlan.connect, the error flag will be set and execution will stop - so wifiSuccess will never get set to true.