Use of noInterrupts causes port to close

[madsci1016]

First off, great job working so hard to make this ESP chip extremely useful by porting the Arduino API. If any of you are in North Florida anytime soon, I owe you some beers.

I've got a sketch that receives UDP packets full of pixel data and pipes it out to some GECE (GE ColorEffects) pixels via a pulse time based 1 wire protocol similar to WS2812 pixels. The UDP packets come in every 50 ms and it takes 23 ms to bit-bang out the protocol to the string.

At first based on the documentation I didn't worry while I bit-banged out the light data as I thought i wouldn't get interrupted by background tasks until I called a delay(), yield() or just returned from the main loop. I know it says don't go more than 20ms without calling a delay, but it could not be helped. The code was stable, however I was seeing occasional (every few seconds) artifacts in the light string that I can only assume are because something is interrupting my bit-banging and as a result bad data is getting sent down the line.

So i wrapped my bitbang function call in-between noInterrupts() and interrupts(). It completely fixed the artifacts, however now the sketch is no longer stable.

After an random amount of time Udp.parsePacket() never returns a packet size. The processor is still running, print statements in my code are working, I can ping the network side from a computer and I've verified my host computer is still sending UDP packets. However I'm getting "Destination unreachable (Port Unreachable)" ICMP packets back from the ESP.

Is there anything obvious I'm doing that causes the ESP to close the port it's receiving data on?

Main Loop:

void loop() {
  
  int noBytes = Udp.parsePacket();
  if ( noBytes ) {
    //Udp.stop();
    //got ACN packet
    Serial.println("1");
    // We've received a packet, read the data from it
    Udp.read(packetBuffer,noBytes); // read the packet into the buffer
    
    int num_channels = (int)(packetBuffer[123]<<8) + packetBuffer[124];
    num_channels--;
    
    
    
    int num_pixels = num_channels/3;
    //long now = millis();
    Serial.println("2");
    noInterrupts();
    for(int y=0; y<num_pixels;y++){
      //for each LED, consume 3 channels. 
      lights.set_color(y, 0xCC, lights.color(packetBuffer[126+y*3]>>4, packetBuffer[127+y*3]>>4, packetBuffer[128+y*3]>>4)); 
    }// end for
    interrupts();
    Serial.println("3");  
    //Serial.println(millis()-now);
    //Udp.beginMulticast(WiFi.localIP(), multiip, localPort);
  } // end if
  
  //
  //
  Serial.print("."); 
  delay(10);
}

I'm not sure if it's related, but I have captured some debug output while testing this:

3
..1
2

Exception (28):
epc1=0x4010345f epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000024 depc=0x00000000

ctx: cont
sp: 3ffea700 end: 3ffeaa10 offset: 01a0

stack>>>
3ffea8a0: 00040000 00a76124 53002200 3ffec650
3ffea8b0: 4000050c 3fffc278 40104d90 3fffc200
3ffea8c0: 00000022 00000030 00000019 ffffffff
3ffea8d0: 402022b4 00000030 0000001e ffffffff
3ffea8e0: 402022a6 00000020 00000013 00003208
3ffea8f0: 00000333 3ffe9958 ff000000 00000a0d
3ffea900: 34343434 3ffee6f4 00000002 3ffe958a
3ffea910: 3ffeaa68 00000024 00000024 00000030
3ffea920: 3ffeaa68 00000003 3ffea98f 40205dd8
3ffea930: 00000009 40202be4 3ffe8b14 3ffeaa68
3ffea940: 00000035 0000000a 3ffeaa68 4020558d
3ffea950: 3ffea98c 00000007 00000003 402060b6
3ffea960: 3ffeaa68 00000001 3ffe8d91 40205dd8
3ffea970: 40201124 3ffe9480 00003000 00000024
3ffea980: 3ffe9488 00000001 3ffeaa68 4020460d
3ffea990: 3ffe8d90 3ffeaa68 3ffe9480 402046b0
3ffea9a0: 00000001 00000000 3ffeaa68 40205eac
3ffea9b0: 40203fa0 0000000a 3ffeaa68 00000024
3ffea9c0: 00000023 3ffeaa68 3ffe9587 402022a6
3ffea9d0: 3ffe9958 00000000 00000016 40101b11
3ffea9e0: 402017ed 3ffe8000 3ffeaa68 3ffeaa3c
3ffea9f0: 3fffdc20 00000000 3ffeaa34 4020184a
3ffeaa00: 00000000 00000000 3ffe99f0 40100378
<<<stack<<<
b„¤d䄆…¤¦…¤„…‡†å‡Ä‡ä¦¦FC£„¤¤„bæ„„†„¤„ÄÄ䄥Ĥ熤Dó„Æ„bŧĄ†E£…†Ä¤bÇd[Connecting]S.A.R.A.H....
SSID: S.A.R.A.H.
IP Address: 10.0.0.43
Connected to wifi
Udp server started at port 5568
...1
2
3
...1
2
3

[sticilface]

The UDP eventually stops responding in my sketches as well. The HTTP continues to work, as does MQTT.
I added a function that is called by a URL, to stop UDP, and start it again, and then my OTA updates (which use udp) start working, immediately.

[madsci1016]

Do you use noInterrupts()? Before I started doing that, I had no issues.

In my application i expect to receive a UDP packet every 50ms, so I added a 'watchdog' routine that closes and opens the UDP port again if it failed to receive a packet after a timeout. I lose a packet or two that way but at least it keeps it running for now.

[Makuna]

There seems to be a very sensitive networking ISR in the core that does not like the interrupts to be disabled for longer than few microseconds. My NeoPixel library no longer works if networking is used with the latest SDK. It also uses NoInterrupts and @sticilface did the grunt work to find out a WiFi interrupt was trying to trigger during it and would cause the chip to reset (I suspect it triggers once is ok, but if it triggers twice before being serviced it will reset).

As it sits right now, I am unsure how any code using NoInterrupts() and networking could ever be stable.

[sabas1080]

I had a problem with websockets within interrupts, should not send anything via serial

[Links2004]

serial based on interrupts :) if you block them you run in a deadlock and then run in the wdr.
will happen when you reach the FIFO limit.

@Makuna
having a separated wifi network for the esp helps much, on my normal network are too many ARP and broadcast packages. with less or nearly nothing other on wifi the NoInterrupts working surprising well,
but normal routers not have a the possibility to simply setting up a other network for the ESPs.
openWRT helps here a lot ;)

[Makuna]

@igrr @Links2004 @sticilface As of the latest findings from SDK people that sticilface communicated to me, total stopping of all interrupts is not supported and will cause resets in the wifi core.
With this new knowledge, I believe we should change the NoInterrupts to set the level at 5 instead of 15, to allow these sensitive ISRs in the WiFi core to continue to function.

[paulo-raca]

I'm having the same problem (Also using NeoPixel library).
Anyone found a way around?

[Makuna]

@paulo-raca If you are using the Adafruit library it will not function due to this. They based their work off my original version which no longer works. But I have a version that "was" functional. It is in the UartDriven branch of my library (NeoPixelBus) which is modification of the original Adafruit library that I added the esp support to but I also made other changes that they could not pick up. I state was in that a few people have stated that it also is acting up with long strings since an interim update since I discovered the above problem.

[paulo-raca]

That's perfect, thank you!

[osos]

#654 (comment) could the NoInterrupt() function as well as the InterruptLock class be amended to allow setting of level like:
NoInterrupt(5) or InterruptLock lock(5)

?

setting the default reasonable for the wifi-interrupt not to be disabled, but allowing specific lib easy access to override the default.

[igrr]

We have a helper macro, AutoInterruptLock, which serves this purpose.
The only 'reasonable' level is 1, i.e. you can use AutoInterruptLock(1);