When my DeepSleep length is 30min or more, the code works i.e. it goes to sleep and then wakes up again.
If I go above that then the application goes to sleep but never wakes up.
The bits of code that I am using for this are
#define SLEEP_LENGTH 60*45
and
delay(100);
ESP.deepSleep(SLEEP_LENGTH * 1000000, WAKE_RF_DEFAULT); // // deepSleep time is defined in microseconds. Multiply seconds by 1e6
delay(100);
Currently nothing is connected to VIN and GND2 as I am powering via the USB port. I will add the VIN power part later.
I read somewhere that instead of a straight short to the RST pin that I should include a resister between D0 and RST. This does not seem to have helped.
I am wanting to put the application into deep sleep for 60min.
Post a link to the library, or libraries. Use the icon to the left of the X2 icon.
60 * 45 * 1,000,000 = 2,700,000,000
says:
Long variables are extended size variables for number storage, and store 32 bits (4 bytes), from -2,147,483,648 to 2,147,483,647.
Since the calculation exceeds the upper end of a long, I suspect that the deepSleep method takes a long.
I guess it takes a signed type, so you can take negative length naps. Any programmer worth a damn would have used an unsigned type, so you could have slept for 4,294,967,295 microseconds (or 71+ minutes).
Of course, any programmer worth a damn would have figured out that sleep for only a few microseconds would have saved any real energy, so would have defined the sleep interval in milliseconds, allow for almost 1200 minute naps. Now, THAT would save energy.
Yes I did think that might be the issue and did also find it strange that the units had been defined as they have been; but then I am still bumbling my way through all of this so who am I to question?
So I suspect that the compiler is doing the math first, in signed long and then promoting the negative result to uint64_t as some humungous positive number. Try casting. Also turn up warnings in preferences to the max and you'll likely see some overflow warnings.