ESP8266 Community Forum

- Thu Jun 29, 2017 11:44 pm #67742 Hi all, I'm pretty new to ESP8266 and "modern" embedded systems. (My background includes building embedded systems 30 years ago on chips that had 256 bytes of RAM, so I'm not completely unaware of concepts, but am essentially unfamiliar with the current state of things).

My problem is that I have a piece of software I created for my ESP-12E board. It works well by itself, but I'm trying to add WiFi networking to it. I also have some very simple tests of WiFiManager, and UDP send/receive that work well (with the same LEDs lit up as the primary piece of code). However, if I attempt to start networking inside this primary software, it blows up reliably.

I can start WiFi.begin, providing explicit credentials for my network, or I can use WiFiManager, it fails the same way (even though it works in isolation from my actual application).

I can get through my startup() function, achieve a connection and IP address, and actually enter the loop function (which currently does nothing whatever with networking) and then it dies and goes into some kind of reset.

So, the root of my problem is that I'm not sure why.

I don't think it's the power supply issues I've read about, since I'm able to turn all the LEDs on, and still execute networking (including send and receive messages) successfully. But, I suppose I can't be sure.

But I also don't think it's the WiFi code, since I'm not even doing anything other than launch the connection (which has succeeded) when it fails.

I don't think my software is taking too long in the main loop, but again, I'm not sure how I'd know.

I did try disabling the watchdog, but although the code compiled and uploaded, I don't know for sure if I got the code right. Certainly no difference was observed.

What should I read to try to start to understand this?
TIA,
Toby

- Sun Jul 02, 2017 1:55 pm #67829 I usually start commenting out chunks of code until the problem stops. Then examine the last chunk of code.

If the code doing lots of computation, be sure to call the yield() function. Even when you program is not using WiFi, background WiFi processing must be done. Calling yield() or delay() allows the background processing to be done. Returning from loop() also allows background processing to occur.

Disabling interrupts for more than a millisecond will also result in a crash. If you are trying to bit bang GPIO with interrupts off, expect crashes.

The exception decoder can also help.

https://github.com/me-no-dev/EspExceptionDecoder

EDIT: And see this thread.

viewtopic.php?f=6&t=15359

- Mon Jul 03, 2017 9:56 am #67872 Many thanks for all the input. It turns out that a math error was creating a very large argument to the delay call at the end of my loop() function. The computation was supposed to create even-tempered looping in the face of variable function execution time, and worked perfectly without wifi, but was occasionally (particularly right after wifi startup, of course) would create this negative, and therefore huge, delay with the wifi added. A simple check for "we're already late, so don't delay at all" has fixed it.

What's interesting to me is that the delay function was causing the failure; I had thought that it, like yield, was designed to allow the necessary background processing. Indeed, i still suspect that it does, but that the problem was that the failure to finish the loop() function was the cause of the reset. That information is probably coded in that reset information if I knew how to parse it.

Anyway, all is good now, thanks for the pointers
Cheers!