setWatch on ESP8266 is not stable ?!

I use D5 and D4 of ESP8266 to detect pin status using setWatch.

setWatch(function updateDIN1() {
// ...
}, D5, {repeat:true, edge:'both', debounce:100});

If I connect D5 to normally GND, then the ESP8266 will detect many interrupt, and
ESP8266 can not continue to run the other script program.
However, If I connect D5 to VCC via pull-up resistor, then when I change the D5 to GND, then
I will get many interrupt, and ESP8266 to busy accepting interrupt from the setWatch..

Is there anyone have this kind of problem ?

Regards,
Maman

@maman, I'm not surprised... because a 8266 is just one processor and a very significant part of its processing capacity is Wifi stack ASSIGNED... and if it does not get it... it flunks. 8266 timing has hard stops: every x ms the Wifi stack expects the full processor being available to just do Wifi work. If processor is tied up with something else... Wifi / all 8266 crashes.

What though seems fishy to me is the sequence you get without even doing something... so I can think of bad connections, iffy power supply, etc. (assuming setWatchI() actually works on 8266).

Even though 8266 is very popular and many things can be done with it, it is not though to do other things than serve Wifi through AT commands. Period.

Get a Pico and combine it with your 8266 - or better: get a Espruino-Wifi, and you are best off, because the embedded dedicated (slave) 8266 does Wifi very well and you free what ever to do on the JS side.

So I just flashed a LoLin ESP8266 board, with 1v99, and tried to replicate your problem. SetWatch performed as expected when connected to Vin or GND. It detected the state change when I touched the pins. I used your code example.

I have worked with setWatch alot on the ESP8266, and its pretty stable. As an example, after I tried to replicate your problem, I wired up a rotary encoder and used the "encoder" module to test. It uses setWatch under the hood. Here is my code (just a copy paste from the "encoder" module page).

var step = 0;
require("Encoder").connect(NodeMCU.D5,NodeMCU.D6,function (direction) {
  step += direction;
  print(step);
});

As you can see I got a couple of errors (probably my pin choices), and a warning about FIFO_FULL, but this didn't affect performance in anyway. I was spinning the encoder as fast as I can. So thats about 22 events in 2-3 seconds, which is not bad. I literally span the encoder as fast as I could and everything was fine. The FIFO_FULL warning only came after a restart of the module. It could perform for hundreds of turns after without problems.

 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 1v99 (c) 2018 G.Williams
Espruino is Open Source. Our work is supported
only by sales of official boards and donations:
http://espruino.com/Donate
Flash map 4MB:1024/1024, manuf 0x20 chip 0x4016
>
=undefined
ERROR: Pin state not supported
ERROR: Pin state not supported
-1
-2
New interpreter error: FIFO_FULL
-3
-4
-5
-6
-7
-8
-9
-10
-11
-12
-13
-14
-15
-16
-17
-18
-19
-20
-21
-22

So this suggests to me Espruino is fine. And that as @allObjects suggested your problem is electrical. Please note, that not all ESP8266 boards are the same or of the same quality. For example both the ESP-201s, and the AT-WITTYs were notoriously difficult to deal with from flash memory corruption to extremely flakey power. Other boards (WeMos D1 Mini comes to mind), operate pretty flawlessly.

Anyways check your setup again I'd suggest.

@hungryforcodes, thank you for validation. Sad to hear about thinks like flash memory corruption - that's as bad as it can get, and all bets are off. Saving a green buck and spending many (hours) grey (brain) bucks... including the one of others. - Yes, sometimes the most precious and not replenish-able resource - time - is more readily available than money, bottom line (over time) though, time always is in shortest supply... (maman, never mind my assumption).

@allObjects Well I was doing the work in production quantity, so we're talking about 100s of boards from different sources, which I did deliberately. One of the reasons was to exactly test reliability of different mantufacturers and find out which ones could be used effectively for productization. I thought the data I gathered was extremely valuable, at the time. But yes time is important! :P

@hungryforcodes, ...was only talking from prospect of having fun with Espruino... doing business is a totally different ball game: no brain time can fix money set in sand. Like running code on not pre-validated data and then being scratching the head about surprising results. With great numbers of IoT devices in the field all over the place and failing (intermittently) there, fixing an issue is not just producing a few more to drop the non-passing with them in the factory.

What burn-in tests of the final product do you have? ...and how long are they running? Does the burn-in test run additional code - on top of the intended application code - to do stress test beyond the regular stress limits?

What is the test result gathering / presentation and degree of automation of the test(s)?

@hungryforcodes, @allObjects, thanks for the reply. I use ESP-07 from Ai. Now, I am developing lamp controller that can be remotely controlled by MQTT protocol. However, I want to use the previously mechanical switch to control the lamp, locally, in case the network failed. I connected directly the mechanical switch to pin D5 of esp8266 tied-up with 10K resistor to VCC. It seems that the problem is the mechanical switch. I have tested the code below :

print("Starting watch set test\n");
var testPin = D13;
pinMode(testPin, "input");
var watchId = setWatch(function() {
  print("The callback function was called for a pin I/O change\n");
}, testPin, { repeat: true} );
print("A new watch was set up with id=" + watchId + "\n");

And the result is there are many callback function was called, and the ESp8266 was crashed.

then I put a small capacitor on the switch terminal, and add debounce at 100, then it is run well.
Thanks for your attention.

@maman Thats great! I'm happy you got the problem resolved. It can be very annoying to have mysterious, unexpected issues like this.

@allObjects Yes, it was part of a wireless lighting product I was developing. In the end I couldn't get the costs down enough and abandoned it.