ESP8266(wemos d1 mini) interrupt constantly alerted without cause.

Hello, I have a problem with an interrupt that alarms itself for no reason.
This interrupt is handled by the encoder, it is connected to pin D4, as a knob press (spinning on pins D3 and D5). Encoder library. Everything was working fine until I included wifi operation in STA mode. After knocking out this code the problem persisted, I saw that esp was still connecting to the stored network despite knocking out the code, so I compiled the code with the wifi.mode(OFF) line and then my code again. The module stopped connecting, but still the interrupt alerts probably "every frame"(b. fast spam on serial monitor). There is no load in the interrupt, one line changing the value of a global variable of type uint8_t - that's it. Switching the interrupt to another pin makes it not work at all. I have a simple function that counts "frames" and normally it's close to 500,000 per second, but when I include encoder handling (checking every frame if there has been a state change, then ignoring the check if it hasn't been 50ms (debouncing) and rechecking the state after the noise) it drops to the console value, which is 30fps.
I tried an external 10kilo pullup, attached a 1000uF capacitor, disconnected the encoder from the pin, no change. I even checked with the arduino, the analogue pin and the drawing board in the arduino IDE (makeshift oscilloscope) what the state of the D4 pin on the esp looks like and it is ok, when I press the encoder it drops to about 60 (about 0.29V) and when I let go the state of the pin stays at one level without even special noise at about 680(3.32V) (arduino on 5V).

What could be the cause or what other data is needed.

To get rid of the wifi connection, upload "blank.bin" which you can find on the web, in your case version 4M. This will overwrite the flash area where the wifi connection data is stored. Then upload your code (the one without wifi support).
This will solve part of your problem, the rest is written about @khoam .

Greetings

You don't want to auto connect to WiFi then you have the function WiFi.setAutoConnect(false);
In the arduino tools under Erase Flash you can choose to have it erase all flash every time you upload a sketch (as above).
If you have long loops with lots of instructions, use yield(); or delay(0); in each iteration to avoid triggering the watchdog. You can always disable the software watchdog (not recommended) ESP.wdtDisable(); but the hardware watchdog will still work.

Ok I chose to overwrite all flash memory when uploading the sketch, thanks for the hint.

khoam wrote:

I guess this is about the watchdog? You'll need to stop the serial monitor when the logs appear and paste the WD cause information here - it's usually quite helpful. At this link you have information on diagnosing the cause of a WD on the ESP8266:

.
Correct me if I'm wrong, but the watchdog is what restarts the module when it crashes or something. It then pops up a stack trace and restart log. The thing is, this doesn't happen to me. I don't have reboots. It is about an interrupt registered on pin D4, which calls itself nonstop.
A small correction, where I wrote that the loop laughs 500,000 times per second it laughs 50,000 and where I wrote that 30 it laughs 3.
Also, if I comment out //attachInterrupt(D4, handleKey, RISING); it goes back to its speed, but stops working and pressing the encoder and spinning it even though the spinning works on separate pins D3 and D5.
What annoys me the most is that it all worked as expected on this code, and stopped working as soon as I attached the wifi, while it didn't start working again once I removed the wifi.
The whole code has thousands of lines (not in the loop itself of course), I will try to paste the relevant ones:

[/code].

It didn't change anything. HandleEncoder only checks if the variable has been changed, nothing there affects the interrupt itself. moreover, in Encoder.h both functions are used multiple times so when I use them it is more likely to be overwritten anyway. Here are the contents of Encoder.h:
.

Encoder.cpp:
.

After disabling the operation on pins D3 and D5 (turning left right) still the same. I have the impression that it happens faster. The effect of the click is to jump over the menu items visible on the OLED display, it seems to me to jump faster.
Can the interrupts on D3 and D5 affect the interrupt on D4? I'm still confused as to why this worked before. I recall that I used to have problems with the pin control in the ESP. Sometimes it was the case that a pin worked normally, but when, for example, I started to do something on another pin, the first one stopped working. For example, when pin D1 was not in use, I could do whatever I wanted with pin D2, but when I set D1 to high, I could no longer control pin D2. Such miracles happened, to this day I don't know why, of course I don't remember the pin numbers, I gave examples. Here the problem is even stranger, because I didn't connect or disconnect anything at all, I didn't even change anything related to the pins. Nothing like this has ever happened in the arduino, only the esp freaks out.

I tried another pin, but then it doesn't work at all. It seems to me that other pins may not support interrupts.
Rotary Encoder Module KY-040 Arduino / PIC / PI
I don't want to give a link, because as far as I remember forbidden.
However, it probably doesn't matter, because even if I disconnect it from pin D4 it doesn't change anything. As I wrote above, it's not the state of the pin that affects the triggering of the interrupt. I measured with arduino + drafter from serial port the state of D4 pin with encoder disconnected and it is still high there.

Unfortunately there is still no change. Yes yes, I know that disconnecting doesn't disable the service, I just meant that it doesn't matter what encoder I have, because it's not the one causing the problem, as evidenced by the fact that when I disconnect it, nothing changes.

Hmmm you're asking where in the code and at the same time saying you're not asking about that bit, well false is assigned right there.
The interrupt on the pin sets the value to true, while the loop every cycle executes the HandleEncoder() function, which contains the following
.
and it is at this point that the value false is set.
I understand that you want to suggest that setting true/false loops through faulty code and this has the effect of spamming the functions, but two questions remain, why was it working fine before and stopped even though I didn't change this particular piece of code? The second question is why when I change the setting of this variable
to
.
this of course on the oledo stops the menu jumping because I have removed the response of this menu to the interrupt, but the serial monitor is spamming me with the variable count at a rate of about 800/s. In this case I have cut off any effect of this variable on the interrupt behaviour. I also disconnected the encoder cable from pin D4. Now the interrupt only triggers a spam on the serial monitor. I should add that connecting pin D4 to 3.3V or ground changes nothing. For the rest, its state was tested before and no change is visible there, but just to be sure, I checked such two options.
Of course I checked on another wemos and it works the same.

khoam wrote:

Converting the isButtonPressed variable to a count in the interrupt handler will not help here at all.

.
It probably won't help in terms of the correctness of handling this variable, but it will help insofar as we get rid of this variable from the issue of the problem altogether. Since it is no longer involved in the interrupt, the cause of the problem was certainly not or was not the only one. Incidentally, the isButtonPressed variable is only set to true in this interrupt, when defined it is set to false.
However, if we disconnect the variable (the change of the value of which, by the way, was not the cause of the interrupt anyway, but its effect), disconnect the encoder from the pin, connect the pin to GND, power supply or leave it unconnected (which is a dangerous option, because its state now depends on a mass of factors over which it has no control), the interrupt continues to be triggered uninvited and this is the key problem.

khoam wrote:

This already looks a bit like voodoo

.
I can usually handle things from this world

khoam wrote:

Are you sure you used digitalPinToInterrupt()?

yes

khoam wrote:

Have you tried on a pin other than D4?

.

grankee wrote:

Switching the interrupt to a different pin makes it not work at all.

khoam wrote:

Maybe it's better to move it to loop() - then there's more control over distinguishing the on/off states and you have better control over bouncing.

.
This was the first solution I tried in general, but there was the problem described above, i.e. the pin state reading in the program was not true. The state was still LOW or HIGH, I can't remember anymore, even though the physical pin state reading said otherwise. There was also the problem I described above, that when I started to do something on the next pin, the one that was working so far stopped working and it was impossible to either set the state or read it correctly. Operating the encoder as it is now was the only working solution, now it is no longer.

khoam wrote:

Is the operation of this button extremely critical i.e. the response to pressing it must be instantaneous?

.
It's hard to say, you know, the encoder is used to navigate through menus and change settings so it needs to be fast enough for this to happen smoothly. There are delays of a few tens of ms in the ds18b20 support in the library and I had to reprogram this to get them out, because it could be felt that sometimes turning the encoder didn't catch on. I don't remember if the clicking did either. Now the ds18 works on a similar principle to debouncing, it counts down x amount of time since the last action and executes the next one if x amount of time has passed, this way I got rid of the delay altogether.

Ok, admittedly on pin D4 it doesn't work, but I switched to pin D7 and the press works. Now there is a problem with turning left right. Twisting the encoder doesn't work as a button, it only compares the state of one pin while changing the state of the other, so ideally it would be best to register both twisting pins as buttons and compare the state of one while changing the state of the other one to determine if I'm twisting left or right, do you have any better ideas on how I can do this?

//edit wait because it doesn't seem to work, but it works 1/1000th of the turns, I need to post where the problem is.
//edit okay, this time the problem is in my code, because when I dry paste serial.println into every twist detection it spams nicely, so I will fight it. The encoder press problem seems to be solved for now, although I'll still leave the thread until I get the wifi up and running above and make sure it continues to work.
The problem still remains with the D4 pin not working as it should, my easybutton didn't work on it, it doesn't detect a change in state of the pin at all. It is also impossible to read its state as it keeps showing HIGH. Interestingly, as this is the pin of the built-in LED I can tell that the state is actually changing as indicated by the LED turning on and off. Furthermore, digitalWrite is unable to change the state of the pin. Still high. of course I use the pinMode function

Pin D4 is probably the worst possible pin you could have chosen. On this pin is TX1 and it is in high state, also during boot, and there is a led on it.
Here are the truth tables for the GPIO on the esp8266 https://www.letscontrolit.com/wiki/index.php?title=Configuration

Greetings

Thanks good man. I'll check later that everything works with wifi and write back.

As I am following the substantive discussion in this thread with interest, I would be grateful for feedback as to whether it has helped. In my designs, I generally go for pins D5-D8, unless I need more then I choose additional ones from the least cumbersome.

Best regards

it looks like d3 has refused to work along with d4. D5 and D7 I use for the encoder and one pin is still missing. D6 supports the ds18b20 thermometer, D1 and D2 I2C. Missing pins I have the PFC connected but have not been able to read the actual state of the pin, I only use what outputs. Any ideas?

Try D11 or D12, possibly D8 for rising edge detection i.e. pin shorted to vcc, as it has pulldown.

Greetings

Try DS18B20 rewired under D3, and fire a button on D6.

Greetings

khoam wrote:

What parameter are you passing to pinMode() for D3 and D4?

There are two parameters for the pinMode().
pinMode(D4,INPUT);
INPUT_PULLUP does not work either.

khoam wrote:

How did you define the EasyButton constructor for pin D4?

.
EasyButton leftEnc(LEFT_PIN,35,false);

Here's the thing, even when I don't use easybutton but just check the state of the pin in the loop it doesn't change. It only spits out a 1 once on power up, then silence, and I alternate shorting it to ground and vcc
.

Slawek K. wrote:

Try D11 or D12

.
are not even pulled out

Slawek K. wrote:

Try DS18B20 rewired under D3, and fire a button on D6.

.
does not work on pin d3

khoam wrote:

Same problem as with D4. See above. D3 also already has an external pull-up resistor to supply.

.
Ok, but I can't understand why this interferes with operation. After all, for example in the arduino all pins have an internal pullup built in and you can always use it, yet the pins work. I thought the pullup's job was to set the state to a specific high state so that it wouldn't be random under interference, not to put the pin out of use completely. If that was to be the case then who would bring it outside and why? Why did they work before? Why if pin D4 has a pullup then the interrupt was detected nonstop, after all the interrupt was supposed to be alerted by a rising edge, not a high state, and there was a high state there all the time.

//edit I managed to read the state of the pins in the PFC, the problem is however that reading the state of a pin every 1 loop slows down the ESP from 37000 executions per second to 3500 or about 11 times. All unused pins do not work.
//edit I found the interrupt pin in the PFC, and it even works, the problem is that when I short-circuit a pin to ground the OLED starts spitting out bushes for a while (it works on the same I2C bus to the PFC).
//edit ok it seems that when I simply read the state on d5 and react to its change, the display does not swirl (earlier I tried with interrupt)

//edit the encoder on the pfc works together with the network.

Added after 17 [hours] 2 [minutes]: .

Summary:
pins D3,D4 (even though they worked before) and D0 and D8, and by the way also A0, I have not been able to get them to work. The status on them is set like this and not different and nothing can be done about it if anyone has any more ideas I'll turn a deaf ear.

Encoder connected to PFC, as if anyone needs it I wrote a mini library, probably not perfect but it works. Since the topic has already been set up, maybe someone else will benefit.
https://github.com/grankee/Encoder_pfc8574

If you don't tighten the encoder to one side of the full stroke and reverse it, it will work as a reverse twist. I haven't had the time or need to analyse all 4 steps of the encoder to eliminate this effect, because when used normally it's ok.