delay(0) behavior changed

[mhightower83]

Basic Infos

• This issue complies with the issue POLICY doc.
• I have read the documentation at readthedocs and the issue is not addressed there.
• I have tested that the issue is present in current master branch (aka latest git).
• I have searched the issue tracker for a similar issue.
• If there is a stack dump, I have decoded it.
• I have filled out all fields below.

Platform

• Hardware: ESP-12
• Core Version: 521ae60
• Development Env: Arduino IDE 1.8.19
• Operating System: Ubuntu

Settings in IDE

• Module: Adafruit Feather HUZZAH ESP8266
• Flash Mode: qio
• Flash Size: 4MB
• lwip Variant: v2 Higher Bandwidth
• Reset Method: nodemcu
• Flash Frequency: 40Mhz
• CPU Frequency: 80Mhz
• Upload Using: SERIAL
• Upload Speed: 460800

Problem Description

A blocking library function that uses delay(0) will fail with Software WDT Reset.

This last worked in Core version 3.1.0

Changes made in commit 39080e3 altered this behavior

MCVE Sketch

#include <Arduino.h>

// Last worked with Core v3.1.0

void setup() {
  Serial.begin(115200);
  delay(200);
}

void loop() {
  Serial.printf("\r\n\r\ndelay(0) test - should never WDT reset\r\n");

  while(true) {
    delay(0);
  }
}

Debug Messages

--------------- CUT HERE FOR EXCEPTION DECODER ---------------

Soft WDT reset

Exception (4):
epc1=0x40100249 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

>>>stack>>>

ctx: cont
sp: 3ffffe20 end: 3fffffd0 offset: 0160
3fffff80:  00000000 3fffff60 3fffff90 3ffee5a8 <
3fffff90:  3fffdad0 00000000 00000000 40201f3c  
3fffffa0:  3fffdad0 00000cc1 3ffee57c 40201069  
3fffffb0:  feefeffe 00000042 3ffee57c 4020199c  
3fffffc0:  feefeffe feefeffe 3fffdab0 40100c05  
<<<stack<<<

--------------- CUT HERE FOR EXCEPTION DECODER ---------------

 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

Exception 4: Level1Interrupt: Level-1 interrupt as indicated by set level-1 bits in the INTERRUPT register
PC: 0x40100249: millis() at /home/mhightow/Arduino/hardware/esp8266com/esp8266/cores/esp8266/core_esp8266_wiring.cpp line 176
EXCVADDR: 0x00000000

Decoding stack results
0x40201f3c: __delay(unsigned long) at /home/mhightow/Arduino/hardware/esp8266com/esp8266/cores/esp8266/coredecls.h line 77
0x40201069: loop() at /home/mhightow/Arduino/Debug/DelayZero/DelayZero.ino line 11
0x4020199c: loop_wrapper() at /home/mhightow/Arduino/hardware/esp8266com/esp8266/cores/esp8266/core_esp8266_main.cpp line 258

[mcspr]

A blocking library function that uses delay(0) will fail with Software WDT Reset.

Any examples outside of Core?

Unintentionally (?) broken in #8802, since esp_try_delay never bothers to do anything with timeout of 0 and treats it as end of usual delay cycle that happens after yield happened.

Arduino/cores/esp8266/coredecls.h

Line 69 in 521ae60

while (!esp_try_delay(start_ms, timeout_ms, intvl_ms) && blocked()) {

Arduino/cores/esp8266/core_esp8266_main.cpp

Lines 168 to 172 in 521ae60

	bool esp_try_delay(const uint32_t start_ms, const uint32_t timeout_ms, const uint32_t intvl_ms) {
	uint32_t expired = millis() - start_ms;
	if (expired >= timeout_ms) {
	return true; // expired
	}

Suppose the fix is to wire this even earlier

Arduino/cores/esp8266/core_esp8266_wiring.cpp

Line 39 in 521ae60

esp_delay(ms, [](){ return true; });

So it calls esp_delay(0) instead of the blocking variant

[mhightower83]

Any examples outside of Core?

Referenced in Issue

• WDT reset with SD card #1255 (comment)

https://github.com/Bodmer/TFT_eSPI/blob/eb68e056d95f0f62bc08eab9242f5855518917cd/examples/Generic/Viewport_Demo/Viewport_Demo.ino#L83

https://github.com/Bodmer/TFT_eSPI/blob/eb68e056d95f0f62bc08eab9242f5855518917cd/examples/Generic/TFT_Screen_Capture/screenServer.ino#L85

https://github.com/tzapu/WiFiManager/blob/3a303eeb45de78dba9987808bc5bef6440a0f8f8/WiFiManager.cpp#L1660

This one is interesting. It calls loop() and delay(0)
https://github.com/earlephilhower/ESP8266Audio/blob/12131e9826283ec19cc728476c1dc1479bb7c09d/src/AudioGeneratorTalkie.cpp#L43-L46

https://github.com/Bodmer/TFT_eSPI/blob/eb68e056d95f0f62bc08eab9242f5855518917cd/examples/320%20x%20240/UTFT_demo/UTFT_demo.ino#L140

https://github.com/earlephilhower/ESP8266Audio/blob/12131e9826283ec19cc728476c1dc1479bb7c09d/src/spiram-fast.h#L92

Suppose the fix is to wire this even earlier
...
So it calls esp_delay(0) instead of the blocking variant

That was my thinking. However, with delay(0), I wonder if there might be unintended consequences with more clever code.