I have a project which essentially involves WiFi, a web server, and an LED. I'm using the Inbuilt LED on my ESP8266 for testing at the moment. I am using the Arduino IDE for programming.

I had a problem where my code would crash after connecting to WiFi. By commenting out functions in my loop, I narrowed down the crash problem to my function that handles the LED. Here I ran into a problem, commenting out each block of code individually, and even a few at once, I wasn't able to prevent the crash. There must be more than one line causing the crash. Commenting out the entire function was the only thing that worked.

After hours of troubleshooting, I was left at the stage where I had the contents of all the if statements and loops and such commented out. Here is what left me utterly confused. Here is the if statement:

    Serial.println("websocket is active, setting brightness");
    analogWrite(LED_BUILTIN, 1024 - lightBrightnessAdjust);
} else {
    //other stuff with more if-statements that are empty

At this point, if I comment out the analogWrite line, the program works fine. But if I leave it like this, it crashes after connecting to WiFi. (I didn't post my entire program because it is over 1000 lines long).

The baffling part about all this is, webSocketActive is never set to true prior to this point in the code... The Serial.println() never does anything, meaning the ESP definitely doesn't execute the instructions inside the if statement. But, for some inexplicable reason, simply having the analogWrite() uncommented crashes the program, even if it never executes that line.

I've also had other issues where putting some sort of Serial.print() function in the loop to repeatedly run somehow doesn't make the code crash. Could someone let me know what is going on?

  • Sounds like you could have some form of buffer overflow or variable alignment issue, and adding / removing code randomly changes allocations of variables or constants. You should turn on debugging and see what the crash actually is. – Majenko Oct 11 '19 at 10:54
  • @Majenko So, I turned on debugging for WIFI+CORE and some other stuff. When my first test worked, I uncommented everything else in the function. It works. Why? What change does turning on debugging make? – skillz21 Oct 11 '19 at 11:24
  • It basically adds a load of serial prints... so it does something similar to your program changes. With debugging off and it crashing do you get an exception code on serial? – Majenko Oct 11 '19 at 11:25
  • Yes I do, it's a hardware watchdog reset, so no stack dump. rst cause:4, boot mode:(3,6), wdt reset. The thing is, as I pointed out in my post, when I added a Serial print into my loop (or just into my function, which is in the loop) the program wouldn't crash. Why would this happen? – skillz21 Oct 11 '19 at 11:29
  • It's impossible to say. – Majenko Oct 11 '19 at 11:38

I think I might know the problem (maybe you've fixed it after two weeks) but your analogWrite(Pin, Val)might end up being out of range, remember that analogWrite only takes an int of 0 to 255 therefore if your lightBrightnessAdjust variable is lower than 769 then we will get an int above the accepted input range of analogWrite().

I know the code never actually runs but it still compiles and maybe Arduino doesn't like even a possible error.

Maybe I didn't explain it very well but here's the Arduino documentation for it.

Another possible solution could be perhaps you could try defining int amount = 1024-lightBrightnessAdjust; variable beforehand and then entering the variable into analogRead because it could be fussy about doing math inside the function params (just a thought)

| improve this answer | |
  • Turns out that my code wasn't the issue. The MDNS.update() in the loop was what was causing the code to crash. Commenting that out fixed the issue. – skillz21 Oct 26 '19 at 22:25
  • Overwriting an array could clobber that functions return address.
  • Allocating from the heap, enough memory for the up-growing heap and the down-growing stack to collide, could cause or create the conditions for clobbering function-local data, function return-return address, or heap data, including the heap meta-data required to de-allocate that heap-block.
  • Writing through an uninitialized or overwritten pointer can cause about any memory corruption you can imagine; and the result can be data dependent and/or data-memory map dependent, and quite possibly non-repeatable.
  • Clobbering the interrupt vector of an enabled interrupt can cause improperly jumping into any part of your code, and is quite likely to be unrepeatable.

There's too much we don't know about the unseen rest of your code to do much more than speculate on possible points-of-failure.

| improve this answer | |
  • Turns out that my code wasn't the issue. The MDNS.update() I had in the loop was what was causing the code to crash. Commenting that out fixed the issue. – skillz21 Oct 26 '19 at 22:26

Turns out that the MDNS.begin() in setup and the MDNS.update() in the loop was, presumable, causing some sort of undefined behaviour, since the code didn't always crash. I commented out these two lines, and the code works fine now, minus the MDNS.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.