An archive of as of Saturday January 26, 2019.

Esquilo seems to be stuck in a loop?



I was running the following PWM code snippet from the documentation and at first it did not seem to work. I set a breakpoint and stepped through the code and sure enough as the pwm.on() lines were executed my scope showed that the expected output was there. However as I stepped to the last line of code the PWM stopped. I had expected the PWM to keep running.

// Create the PWM instance
local pwm = PWM(1);

// Set the frequency to 2kHz

// Set the duty cycles
pwm.duty_cycle(0, 25);
pwm.duty_cycle(1, 50);
pwm.duty_cycle(2, 75);

// Turn on channels 0-2

In order to keep the PWM running I added a while(true) line to the end of the code so I could look at the timing relationships between the 3 outputs on the scope.

As soon as I saved and ran the code, the browser informed me that I had lost contact with the Esquilo. The IDE was dead and there was nothing I could do to contact the Esquilo. Hitting reset or powering it up and down does not help.

To me it seems that the Esquilo is stuck in the while (true) statement and the RTOS is not servicing the IDE so I can't kill the nut. It seems to be running the boot.nut on reset as expected since the 3 PWM signals come up after reset and power up.

The attached scope trace shows the reset sequence. The blue line is the network LED voltage. It goes low about 1 second after reset when the network LED illuminates, and then about 500 msec later the 3 PWM lines start. I cannot ping or get any response from the Esquilo over the network. I have tried to communicate over the USB. It is recognized as a com port but it is not responsive to logins. I have a second Esquilo to test and I am sure that the USB and network are working properly.

So the question is: Is there some way to get the Esquilo out of this infinite loop or is there something else wrong here that I am missing?


I'm not sure why the PWM output stops when you run past the last line. I have similar code that works without the while loop, but when I run yours I reproduce your issue.

The loop is a good work-around. You just need to add a delay(100) to it to avoid the IDE starvation. I don't think the starvation should happen, as the Squirrel VM executes in a bounded time-slice. I think we just need to tweak the slice time and the heuristic that detects loss-of-comm on the IDE side.

I will look at both the PWM and the IDE starvation issues. Thanks for the good description (bonus points for the scope trace wink ).


Is there some way to recover the Esquilo? It is basically bricked because I can't get the IDE up and running.


Ah, sorry. I missed that part.

This image: will clear all your settings, including the "auto run boot.nut". Unfortunately, this will also clear all your other settings, including your Wi-Fi config.

Load it with the EOS Update instructions, here:!eos-update

Then reset your board and do the update again to put the current release back on, downloadable from here:

You should then add add a delay(100) to your while loop and test it before migrating it to the boot.nut.


Thanks Patrick. Everything is up and running again.


Sure Greg. I just remembered that this will also delete the private key and client cert used by our secure tunnel to talk with the Nest cloud site. If you can please send your system ID (available about menu) to, I'll get you another.

Again, sorry for the trouble.


@patrick, ahhh maybe this is why one of my cards refuses to show up via nest. I'll ping you with the sys ID.

@gwziebe, I also have a project working with pwm's (for servos) and have to put it in a loop to keep it running. Odd. But, occasionally the loop seems to take over and I lose the connection as well.. servos just keep running and I can't get in to stop the process (even after pressing reset). My workaround is to pull the sd card and then hit reset. When it boots up it can't find your boot.nut so returns control back to the IDE. You can then hot plug the sd and reload the file directory.


@mdoan7 Did you download and update with the erase_esquilo_air.img at some point? That should be the only way to zap your key and cert.

And, for your servo project: do you have a delay() call in your loop of some amount, say >= 10?


@patrick No, I've only updated to .2.img using the published procedure. Nest shows its local ip as the first one it was registered with when I got the board. The board has since been assigned a new local ip that is different than what's displayed via nest details tag. Nest shows it as offline all the time.

I do have a delay in my loop (was 1.. .and bumped to ~10 at last edit). it's much more stable now will sometimes still lose/lockout the connection.