[Solved] ESP8266 problem on Espruino pico

I meant that the garbled output at the start is a firmware issue.

Just tried with another AP. Same error.
The wifi.at command also does not seem to work (see below).

Tomorrow I'll put on a scope and logic analyzer and try to see what's happening.

=======================================

wifi.at("AT+GMR\r\n",1000,print);

gives me the same error (on both modules)

=undefined
Uncaught Error: Expecting a function to call, got Object
at line 1 col 6
wifi.at("AT+GMR\r\n",1000,print);
----^

Ahh - yes, I think it might be outputting at the wrong baud rate right after it starts? Odd that you still get problems though.

You'd need to do: wifi.at.cmd("AT+GMR\r\n",1000,print) as is in the post (with the extra .cmd in it).

I made a mistake when I initially posted, and then corrected it 30 secs later - maybe you copied the code from the notification e-mail you got, which wouldn't have updated?

Thx Gordon, I hadn't noticed. I picked up your initial post seconds after you wrote it.

However, I suppose that

wlan.at.cmd("AT+GMR\r\n",1000,console.log);

is not supposed to give me

AT+GMR

but rather the version of the firmware running?

Yes, however you can turn echo off first (it should have been turned off initially, but it looks like the module restarted itself) using:

wlan.at.cmd("ATE0\r\n",1000,console.lo­g);

Hmmm,

      wlan.at.cmd("ATE0\r\n",1000,console.log);
      wlan.at.cmd("AT+GMR\r\n",1000,console.log);

gives me

ATE0
AT+GMR

So, in effect, it just echoes.

That really is strange. Maybe try wlan.at.debug() before sending those commands - it should give you some idea of whether anything else is being sent back. As far as I know the response should look like:

wlan.at.cmd("ATE0\r\n",1000,console.log)­;
ATEO
OK
wlan.at.cmd("AT+GMR\r\n",1000,console.lo­g);
VersionNumber

I'm going to try to find some larger capacitors. I currently have 3 uF on them, but in both cases it doesn't seem to be enough. On the ESP12 board I have, there's a 100uF. All in all it's weird, because the getAPs command runs without problem (even without the caps), but anything else gives me troubles.

Yes, that might help. Interesting the ESP12 board has got such a big cap on though!

I suppose getAPs probably doesn't try and transmit anything - I guess it's just reporting on the SSID broadcasts that have been received? Presumably non-radio things like getVersion work though?

Exactly. The moment the radio TX is turned on, things go wrong. My power supply is however a powered USB 3 hub. So it shouldn't be a problem.

New tantalum caps arrived. 10UF each. Same problem, on both modules.

This may be a stupid question, but putting a cap on the pads does mean on the 2 squarish pads on the shim, right? (If someone says no to this, I'll eat my hat)

putting a cap on the pads does mean on the 2 squarish pads on the shim, right?

Yes, that's right...

While your powered hub shouldn't have problems, have you tried connecting the Pico to anything else (like straight to your computer) just in case there is some issue with it? Also, are you plugging the Pico straight into the hub, or using an extension cable?

Yup, did that. Straight into a PC USB port. Same issue (on all three pico's)

Found something:

                  wifi.getVersion(print);
                  console.log("Connecting to WiFi");
                  wifi.connect(WIFI_NAME, WIFI_PASS, function(err)
                      {
                          if (err) throw err;
                          console.log("Connected");
                          // print IP address
                          wifi.getIP(console.log);
                          // Create a server
                          require("http").createServer(pageHandler).listen(80);
                      });

gives me

echo(0);
=undefined
Waiting for ESP8266 to flush its serial buffer
Connecting to WiFi
null 0018000902-AI03
Uncaught WiFi connect failed: no change
at line 2 col 42
if (err) throw err;
.....................^
in function "b" called from line 1 col 37
{"OK"!=a?b("WiFi connect failed: "+a):b(null)}
.......................................................^
in function "b" called from line 1 col 26
{c=void 0;var d;b&&(d=b(a))?(c=p,b=d):clearTimeout(e);void 0...
.......................................^
in function "c" called from line 1 col 325
...f&&(ef,n=!0);n||c&&c(k)}a=a.substr(d+1);"\n"==a[0]&&(a=...
.............................................^
in function called from system

Now,

                  //wifi.getVersion(print);
                  console.log("Connecting to WiFi");
                  wifi.connect(WIFI_NAME, WIFI_PASS, function(err)
                      {
                          if (err) throw err;
                          console.log("Connected");
                          // print IP address
                          wifi.getIP(console.log);
                          // Create a server
                          require("http").createServer(pageHandler).listen(80);
                      });

results in:

echo(0);
=undefined
Waiting for ESP8266 to flush its serial buffer
Connecting to WiFi
Connected
null 192.168.0.214

Commenting out the version command makes the script run as it should. The version command on itself however, does run as in the following:

                  wifi.getVersion(print);
                  //console.log("Connecting to WiFi");
                  //wifi.connect(WIFI_NAME, WIFI_PASS, function(err)
                      //{
                         // if (err) throw err;
                         // console.log("Connected");
                          // print IP address
                         // wifi.getIP(console.log);
                          // Create a server
                         // require("http").createServer(pageHandler).listen(80);
                      //});

which results in:

echo(0);
=undefined
Waiting for ESP8266 to flush its serial buffer
null 0018000902-AI03

So, combining the version command with the connect command results in an error.
Anyone have a clue?

My guess is that it's getting confused because you're starting the connection to it before it's given it's response to the getVersion() (look at the order the messages show up with them combined) - waiting a short time to ensure that it's done might fix it.

That was my guess also. However, as JS doesn't have a delay apparently, I seems I would have to use nested settimeouts for every wifi command. Or is there another way to wait?

You'd have to use setTimeout - or execute the connection in the handler for getVersion, which is called when the version has been retrieved:

wifi.getVersion(function(err, version) {
  print(err,version);
  console.log("Connecting to WiFi");
  // ...
});

Is it repeatable?

The error you were getting (no change) is I think a result of the fact that you're not resetting the WiFi - rather than related to the getVersion call? The ESP8266 was already connected to that WiFi network, so it's telling you that it had nothing to do.

I guess the library should deal with that eventuality, but the example code resets the WiFi before connecting so it's not generally an issue.

I only submitted a portion of the code. It does contain the reset. It's totally repeatable.

But due to this "discovery" I think I (finally) understand what is happening. As you/DrAzzy/I mentioned, I have to nest the calls within one another if I call commands sequentially.

As a non-JS programmer I am not used to the asynchronous execution of code. The problem probably lies in there.

Ahh -that's quite likely - in fact if you called reset but didn't nest what came next then that would explain almost everything.

I had assumed that the totally unmodified example code didn't work for you... Or did it?

You probably know this anyway now, but Espruino isn't multi-tasking, so it relies on scheduling execution of small functions one after the other (which includes all the code that handles the ESP8266).

It's probably most apparent in the ESP8266 library - if you call wifi.reset, it'll return almost immediately (having sent the reset command to the ESP8266)... But that doesn't mean the ESP8266 has actually managed to reset - that takes a few seconds, during which Espruino can be doing other stuff. It's only actually reset when the callback function that was passed to wifi.reset gets executed.

It's really powerful, but it's quite easy to trip up. For instance:

setWatch(function() {
   wifi.reset(function(err) {
    if (err) throw err;
    console.log("Connecting to WiFi");
    wifi.connect("WiFi_Name","WPA2_Key", function(err) {
      if (err) throw err;
      console.log("Connected");
      // Now you can do something, like an HTTP request
      require("http").get("http://www.pur3.co.uk/hello.txt", function(res) {
        console.log("Response: ",res);
        res.on('data', function(d) {
          console.log("--->"+d);
        });
      });
    });
  });
}, BTN, {repeat:true, edge:"rising"});

Looks absolutely fine, but if you tap the button twice in quick succession (or the button bounces) it'll break, because the ESP8266 was already in the middle of resetting, but it'll be told to reset again.

Solution:

1. Put a cap on the shim; I used a 10uF tantalum. (Thx DrAzzy)
   
2. Note that JS runs asynchronous and thus executes the "next" wifi command before the previous one has been completed. Avoid or nest timeouts. (Thx Gordon)
   

Great, glad it's sorted!