Server.sleepfor() Ocasionally hangs IMP <SOLVED>

I have been testing some code that uses server.sleepfor() to deep sleep for a while saving batteries. It wakes up every 30 seconds, and has run for 3 days without problem. Then it hung in an unresponsive state.

Dose anyone have ideas of what to monitor that will give us more idea of what is going wrong?

My test setup draws about 4.5 mA when in deep sleep (Some LEDs stay on for now), and 80-100 mA when online. When it was hung it was drawing 55mA. The LED on the IMP was dark. I didn’t think of trying to ping it (hind site is 20/20) but I did reset the wierless router, and the IMP did not show up in the DCHP after that.

Earlier in my testing I had server.sleepfor() in the main, and it ofter hung up after a few min. I found Hugo’s comment in here http://forums.electricimp.com/discussion/comment/983#Comment_983
and moved the sleepfor() call to a onidle function, and that allowed me to run for 3 days before hanging.

Server log of the event is uninformative. It just went to sleep as expected, and never woke afterword.

BTY: I now see a new “slppeing until xxx” in the server log (this just showed up today).

I’d suggest adding some logging when it boots so you can see if it gets that far. We’ve run devices waking every 5 minutes for many months without issues, and other customers are doing similar thing without any reported issues.

What is your code doing every cycle?

Code is not doing much every cycle.
Reads an A-D pin, and converts value to F.
Dose a server.show() to put the temperature in the planer.
Also dose a few server.logs() at different points.
It also put the temperature into and OutputPort, this is then read by COSM node.

I have some local vars in the sampling function that I was using to average more than one sample. The averaging is commented out, although I left the variable.

I’ll put in some more server.log messages in main to see if I can catch something.

I will also do some house keeping (get rid of the unused averaging).

I must be doing something wrong. I have stripped my code down to the bare essentials, and added server.log() at almost every step of the process. Things still hang after a day or so.
Server log looks like IMP went to sleep and never wakes up.
Section of log ... Tuesday, October 23, 2012 23:24:42: show: Capture: 68.05F Tuesday, October 23, 2012 23:24:42: Main: ran Capture Tuesday, October 23, 2012 23:24:42: Main: Going to call OnIdle Tuesday, October 23, 2012 23:24:42: sleeping until 1351056315000 Tuesday, October 23, 2012 23:25:21: Main: finished imp config ========================================== Tuesday, October 23, 2012 23:25:21: Capture: entered capture: Next will call get_temp.... Tuesday, October 23, 2012 23:25:21: get_temp : entered get_temp Tuesday, October 23, 2012 23:25:21: get_temp : little sleep before reading A-D Tuesday, October 23, 2012 23:25:22: get_temp : read the A-D Tuesday, October 23, 2012 23:25:22: get_temp : caculate reading in F Tuesday, October 23, 2012 23:25:22: get_temp :** Ver 1.4 ** Tuesday, October 23, 2012 23:25:22: get_temp :F : 67.761 Tuesday, October 23, 2012 23:25:22: get_temp :WIFI Signal : -54 dBm Tuesday, October 23, 2012 23:25:22: Capture: goint to put temp in output. Tuesday, October 23, 2012 23:25:22: Main: ran Capture Tuesday, October 23, 2012 23:25:22: Main: Going to call OnIdle Tuesday, October 23, 2012 23:25:22: sleeping until 1351056355000 Tuesday, October 23, 2012 23:25:22: show: Capture: 67.76F
The log stops there.
Here is a full listing of my code
`// Read Temp sensor on pin 2
// My test setup has
// Analog Devices TMP36 connected to pin 2
// 10 K pot connected to pin 1
// Switch connected to pin 8
// Ver 1.1 added server log after sleep at end of code (trying to find why code is hanging up)
// Ver 1.2 Moved deep sleep stuff into function instead of main. Also bunched togethor conversion to F from counts
// Ver 1.3 Averaging of multi A-D throeing out one
// Ver 1.4 Not averaging (simplified trying to find out why things hang up)

// Set up to output data to server
local output = OutputPort(“Temperature”, “number”);
function get_temp()
{
// Variable to store A-D (raw countes)
server.log(“get_temp : entered get_temp”)
local counts;
local readingF;
// letting IMP rest before hitting the A-D
server.log(“get_temp : little sleep before reading A-D”)
imp.sleep(0.5);
server.log(“get_temp : read the A-D”)
counts = hardware.pin2.read();
server.log(“get_temp : caculate reading in F”)
readingF = (9.0/5.0) * (((counts / 19859.09) - 0.5) * 100) + 32;
server.log(“get_temp :** Ver 1.4 **”);
server.log("get_temp :F : " + readingF);
server.log(format(“get_temp :WIFI Signal : %d dBm”, imp.rssi()));
return readingF;
}

function capture()
{
server.log(“Capture: entered capture: Next will call get_temp…”);
// Output the temperature
local temp = get_temp();
// Display the temp
server.show(format(“Capture: %3.2fF”, temp));
// Put the temp out on the server
server.log(“Capture: goint to put temp in output.”);
output.set(temp);
}

// On the forums I found that you are not supposed to put sleepfor in the main (can block firmware upgrades)
// They sudgest putting it in an sub function like this.
function onidle()
{
// Try Deep sleep fo 1 min
server.sleepfor(30);
}

// Configure pin 2 as Analog input
hardware.pin2.configure(ANALOG_IN);

// Register with the server
imp.configure(“Temp Mon”, [], [output]);
server.log(“Main: finished imp config ==========================================”);

// Read temp
capture();
server.log(“Main: ran Capture”);
// Call Idel function which will then call the deep sleep
server.log(“Main: Going to call OnIdle”);
imp.wakeup(0.5, onidle);
// End of code.`
My intent is to read the A-D pin every 30s (give or take a few seconds). Convert the A-D value into temperature. Show that temperature on the planer, and update that temp on COSM. It works fine for a while, and then something gets stuck.

Hum Looking at my posted code I see a few server.log() statements where I did not terminate the line with a “;” Not sure why it works at all without them (Squirrel is not like C). I will add the “;” and see what happens.

Fixed the “;” line endings, but no difference. It ran about 18hrs and then hung up.

That all looks right. Could you describe the hardware setup in detail? WiFi powerup is the highest current bit of a boot (it does a PA calibration sweep), it’s possible that it could die at wakeup if your power supply browned out at that point.

Sure. I am using a https://www.sparkfun.com/products/11401 to hold the IMP. It is powered by a bench supply (home made) providing 5V. The IMP shield drops the 5V to 3.3v Other things in the circuit are.
a) 10K pot between 3.3 and GND with wiper on pin 1. (unused)
b) Switch between pin 8 and gnd (unused)
c) TMP36 temp sensor on pin 2 powered from 3.3V and GND http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Temp/TMP35_36_37.pdf
The IMP shield provides some pull up and LED’s but you can see that stuff on Spark funs schematic.
Power supplies (5V and 3.3V) look solid on a DVM, I will check with a scope tonight. I will also switch from 5V bench supply to a battery pack to eliminate the home made supply.

That board has a fairly small LDO (compared to their breakout that uses our switcher). If you have a big cap lying about (100uF+) try putting it between 3V3 and GND on the P1,P2,etc header just behind the slot?

OK I am sure I can find a cap to hold up the 3V3. I didn’t see anything odd about the 3V3 last night, but my test equipment at home is not the best for finding a single event like this (my scope is older than I am :slight_smile: ).
I did switch over to a battery for the 5V supply last night and that is still running this AM. I will feel silly if its my old trusty bench supply that is causing this, but its easy to fix if that the problem.
If the battery dose not fix the problem I will take a closer look at the 3V3 using a better scope at my day job, and then shore it up with a bigger cap.
Thanks for you help, and I will keep you posted.

If you have long wires on the bench supply that could be the issue. The inductance of the path when there are fast transients (wifi is good at huge fast transient requirements!) then you can see errant behavior.

Putting a big cap at the imp end of the cable will definitely help.

Thanks Hugo. I am a bit embarrassed that I didn’t find this sooner me self, but you where right, it was my old trusty bench supply that was causing my problems. As I posted on Friday (26th) I switched from my bench supply to a battery, and things have been running solid since then. The leads to the battery are shorter so it could be the change of inductance, or that battery is a better supply.

When I switch back to the bench supply I’ll put a bigger cap on the 5V near the 5-3.3 reg and hopefully will never have to look at it again. At least not until I lay out my own Impee.

True story:

At an early Rio Karma (mp3 player) development build, we had 100% yield loss at one station. Every player worked fine up until this station, where the tests passed… but it would never power up again.

Turns out that one operator was turning the bench supply off at the AC after each test, before disconnecting the leads to the player. This was putting about 15V into the 5V input of the product as their bench supply didn’t behave if you cut input power…

Bench supplies can be evil :slight_smile:

The problem defiantly was the power supply.
The battery finally died last night, but the IMP ran solid for nearly a week wakening every 30s.