BS2P low power SLEEP/NAP issue.
LarsA
Posts: 9
Hi all,
I have an issue with stamp low power mode, which maybe someone could help me out with.
I am using a BS2p in an application where it reads temperature (DS1621) and date (DS1307) over the I2C bus. The highest and lowest readings are stored in an external EEPROM (also interfaced over I2C). I am using the BS2p polling functionality to display the current, highest and lowest temperature and time stamp on a serial LCD when the user presses a push-button.
In order to power the application with batteries (e.g. to have it standing alone logging temperatures over a longer time periode in a location without AC mains available), I have tried to use the low power commands SLEEP/NAP. I use a for-loop that splits up e.g. 60 seconds of waiting into 60 one second periodes (in order to not destroy the polling functionality that checks the push-button).
If I use "PAUSE 1000" in the for-loop, everything works perfectly fine. If I replace "PAUSE 1000" with e.g. "SLEEP 1" or "NAP 5", things quickly go out of control... I see this when I insert debug break messages inside the for-loop. When oscilloscope probing the pins, it also seems like control is lost. E.g. I noticed that the I2C SDA (and other signals as well) was pulled low for long periodes (despite the pull-ups).
I have been reading through the reference maunal a few times and I can not find anything that says that the low-power commands should not be working in this type of application (i.e. SLEEP/NAP in combination with polling and I2C). Anyone that knows if it is possible to get this to work properly? And if yes, any ideas of what goes wrong in my application. (I am happy to share the code and schematics of the design if anyone would like to check it closer.)
Cheers,
Lars.
I have an issue with stamp low power mode, which maybe someone could help me out with.
I am using a BS2p in an application where it reads temperature (DS1621) and date (DS1307) over the I2C bus. The highest and lowest readings are stored in an external EEPROM (also interfaced over I2C). I am using the BS2p polling functionality to display the current, highest and lowest temperature and time stamp on a serial LCD when the user presses a push-button.
In order to power the application with batteries (e.g. to have it standing alone logging temperatures over a longer time periode in a location without AC mains available), I have tried to use the low power commands SLEEP/NAP. I use a for-loop that splits up e.g. 60 seconds of waiting into 60 one second periodes (in order to not destroy the polling functionality that checks the push-button).
If I use "PAUSE 1000" in the for-loop, everything works perfectly fine. If I replace "PAUSE 1000" with e.g. "SLEEP 1" or "NAP 5", things quickly go out of control... I see this when I insert debug break messages inside the for-loop. When oscilloscope probing the pins, it also seems like control is lost. E.g. I noticed that the I2C SDA (and other signals as well) was pulled low for long periodes (despite the pull-ups).
I have been reading through the reference maunal a few times and I can not find anything that says that the low-power commands should not be working in this type of application (i.e. SLEEP/NAP in combination with polling and I2C). Anyone that knows if it is possible to get this to work properly? And if yes, any ideas of what goes wrong in my application. (I am happy to share the code and schematics of the design if anyone would like to check it closer.)
Cheers,
Lars.
Comments
Hi Mike,
thanks for your reply. Yes, that is exactly that looks strange to me... as you say, the pins should be floating and thus "high" (pulled high by a 4.7kOhm resistor in the case of the I2C signals; for other pins like EEPROM write protection, I used 10kOhm to pull it high). I will check it again so that it really is like that and not just an incorrect measurement. The "drive low effect" I have observed so far seems to be very random in time but that goes for the whole problem here. At some points, the polling routine is trigged without the button being pushed.
Cheers,
Lars.
Hi Mike,
yes, I realise that. So attached are the schematics (PDF) plus code for the main and sub programs.
In the attached main code, "PAUSE 1000" is used in the FOR-loop and this works perfectly fine. Problems arrise then this is changed to a SLEEP or NAP statement.
Thanks in advance for your time!
Cheers,
Lars.
1) The LCD interface may behave badly during NAP / SLEEP. The +5V to the LCD will turn off briefly periodically during NAP or SLEEP. The data line to the LCD will float from time to time. Best solution would be to use a pull-up on the data line. For the power, if you want the power to stay off while the Stamp NAPs or SLEEPs, you're fine with the existing circuit. If you need for the power to remain on, you'll need a flip-flop on the input of the transistor with its set and reset inputs either pulled up or down. The Stamp would use 2 I/O pins to turn on or turn off the LCD.
2) The STATUS LED needs some kind of current limiter, probably a resistor, unless it has one built-in.
3) The rest of the schematic looks ok.
Unless I missed it, you didn't say what exactly was happening. You said when you use SLEEP things go out of control, but without knowing what happens I would not know where to look for the problem. Mike has some good points, but without more information I can't offer anything additional.
Hi again Mike,
thanks for checking the schematics.
Comments:
1) P9 controls the 5V power supply to the LED by switching the PNP on/off. I inserted R4 as a pull-up here to ensure that the power is off in case of P9 being floating. The idea is to have the supply to the LCD cut off when the LCD is not in use. When testing around earlier on, I noticed that the LCD will draw current over the data line (I believe 10 mA or so) even if the 5 V to it is cut off. Therefore this pin (P8) is disabled in the code when the LCD; if I remember correctly, it is set as an input to cut it off. A pull-down here is something that could be good so I will try this.
2) This is a 5V LED (with built-in resistor).
3) Thanks.
Cheers,
Lars.
Hi Chris,
it seems to me like control is lost when low mode is used. The application does not react to the input pins (switches); sometimes the polling sub routine triggers without any buttons being pushed. As mentioned above, it seems like some pins (like SDA) are sometimes being driven low for some time. When inserting DEBUG flags, it looks like that the stamp wakes up once when falls asleep again and after that things are very irrattic. If PAUSE is used in the FOR-loop, everything is perfectly fine but as soon as NAP or SLEEP is inserted, things are out of control. I hope that this is as somewhat good explaination.
Cheers,
Lars.
Now that I know the problem I have an explanation for you. This applies to both SLEEP and NAP.
Basically each time the WDT wakes up the I/O pins become inputs briefly. So you'll have to use pull-up/down resistors on your I/O pins as necessary to help keep them in the desired state during these cycles. I hope this helps.
Lars,
I noticed some strange results with I2C circuits in the past. Sometime I observed errors when reading and sometime I had to pay attention to the particular order of things or needed to add some small delays to make things working.
Perhaps this link might help http://www.i2c-bus.org/i2c-primer/ especially last 3 sections.
Post your code again but this time show where exactly did you replace PAUSE 1000 with SLEEP 1 commands. and where did you put DEBUG commands that detected errors.
Also, for a moment forget about low power and power your I2C circuits (including all caps and resistors) and switches NOT from from Pin21 but from +5V after LP2950 and see what happens.
John
Hi Chris,
well, that is what the reference manual says and I have been considering this. So there are pullups on both polling input-pins to the switch (that will cause the stamp to enter program 1 when pushed low). When checking with an oscilloscope these pins seems to work perfectly well also when probing directly on the stamp pins; they remain idle as long as the buttons are not pushed.
I spent some time probing around and testing thing yesterday evening. This time I could not see any pins going low like reported earlier, so that could just have been a bad measurement (e.g. poor contact with the probe tip). But behavior is same as before with PAUSE replaced by NAP/SLEEP. The stamp only very occasionally responds to the polling (pushing button 1 or 2). Sometimes it triggers polling without any buttons being pushed. I also inserted a multimeter to check current consumption during execution and this show that sleep mode is entered but timing is irregular and sometimes sleep mode is not entered for long time periods (the the polling is still "frozen"). When checking the LED (should normally light up one time each execution cycle) I notice that this is also very irregular. When I manage to get the polling trigged, I often get bad I2C temperature readings like temperature 0 (all zeros) or 127 (all 1s). So something goes out of control as soon as NAP/SLEEP is using
To me it feels a bit like the stamp is being reset during when waking up from low-power mode. I checked the re-set pin on the stamp for some time but could not see any resets occurring. And I guess that the low-power modes should not be resetting the stamp.
What I would like to know is if there is some general incompatibility between SLEEP/NAP-commands and using polling functionality? I can not find any statements that this would be the case when reading through the documentation (and besides, there is a POLLWAIT command that uses low-power mode).
Cheers,
Lars.
Hi John,
thanks for your inputs. Regarding I2C, the signalling seems to work time most of the time all though I have also seen some issues when reading and when I checked with an oscillscope not too long ago, there are some things that seems a bit strange for the signalling, so testing with delays is one thing I will do.
Firstly, I would however like to solve the issue with getting polling to work for low power mode... the code attached earlier shows debug flags and PAUSE/SLEEP insterted in the FOR-loop (label: "NoUpdate").
It could be interesting to try with powering all circuits from an external 5V-supply as you suggest. When checking with an oscilloscope, the 5V supply on the stamp seems to be supplying 5V also during power down. When checking the B24p schematics from Parallax, the LT1121ACS8-5 regulator shut-down pin is left not connected (NC) as far as I can see, this regulator should then not be affected at all by the power down. That is the reason why I chose to use this supply for some parts and adding an external regulator for the LCD only (which consumes quite much current when it is active; about 70-80mA). Still it would be interesting change power supply from pin 21 to an external supply, so I will try to check this... one bad thing is that I made a nice PCB for the application so I will have to cut a line for this test. :-(
/Lars
I took a look at your schematic and noticed that ATN line (pin 3) is left up in the air....
That should NEVER be the case.
I had a similar problem with random resets etc of BS2 in a noisy environment years ago. I asked Tracy Allen and his suggestion and standard practice was to put a resistor (3k3) in parallel with a capacitor (100nF) from ATN to GND. Also, in case you run your BS2P connected via serial port that ATN line has to be connected through a u1 cap as well.
see this link http://www.emesystems.com/BS2rs232.htm#resets
Try it and report your findings.
John
Hi John,
thanks for your inputs and for taking your time to help me out.
Your inputs are interesting in general and I did tried it out now for my design. No differences unfortunately, and I have been checking the RESET-pin earlier on with an oscilloscope and never seen it going low (this would be the case if ATN is driven high). Besides, this design should not be very noisy I think. But anyway this is interesting to remember for future project involving heavier loads (motors etc.).
So not much progress so far to get my design to work in power power mode. When I use SLEEP/NAP, it seems like the first time the commands executes, either one alone command or inside a FOR-loop as in the attached code, it works well and wakes up after the time set. But the second time and onwards, low-power periode timing is random as well as the response to the polling pins.
Still, I am not 100% if the polling cammands is compatible to using the low-power mode; it would be nice if anyone with deeper knowledge could confirm this.
Cheers,
Lars.
I'm not entirely sure, based on the way NAP/SLEEP work and the way POLLing works that you'll be able to have both running at the same time. It seems like it you want to check the buttons during low-power mode you would use the POLLWAIT instruction in place of SLEEP/NAP. Sadly I never used any of these functions in my previous designs as the current draw of the BS2p wasn't an issue for my project. On battery powered projects I used FETs to switch off high-current devices such as backlit LCD panels. I could try to duplicate your problem with minimal test code, but I may not see the same things as you are since you have extra hardware being affected.
As a note, you were concerned before that the BASIC Stamp was resetting. If it was a single DEBUG at the beginning of the code could help determine that. In the absence of a computer connection the code could start with a FREQOUT to a speaker and play a tone only at the beginning of the code. If you hear this tone any other time then you'd know your module was being reset.
Hi again Chris,
yes, the idea is to have an application that wakes up from time to time to read the temperature. As the temperature is not expected to change so much over time, it could be enough to wake up once very 30 minutes or so. Still, I want it to be possible for the user to be able to read the current/max/min temperature at any time by using polling to wake the stamp and LCD after a short while so this is why I am using polling with a FOR-loop to split delays up in shorter delays. Finally, as the application will only be doing "useful" thing for a very time intervals, it would be nice to have it to power down in between as this would dramatically increase battery life time for an application in a remote location without AC mains. That is the idea behind my project. But it could be that this is simply too much to ask for of a BS2p. I do realise that it is could be a bit challenging for the stamp. I did not find a very good way to use POLLWAIT here when I check the command earlier, but I will think about it again. The POLLWAIT command at least give me some hope that it could be possible to achieve what I want as this instruction includes both polling and low power.
After testing around, I do not really think to resetting is the problem here. Using the FREQOUT for debug is however a nice idea and at least something that I will remember for future projects if I do not use it here.
Cheers,
Lars.