- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have a simple but very low power application running on a PSOC3. When the device goes into sleep mode it essentially disables everything and sleeps for 1000ms (CyPmSleep(PM_SLEEP_TIME_CTW_1024MS, PM_SLEEP_SRC_NONE);)
and then briefly checks a capsense pin before sleeping again. this has been working fantastically up until now. I recently updated my rev1 board to remove a few things and move 2 or 3 pins around. I have also changed the firmware somewhat, but only functional code, nothing relating to the sleep cycle or hardware at all. Before releasing the product to the customer I thought I should quickly verify that the current draw is in fact as low as it had been.
It's not. Whereas it was previously drawing about 10uA in sleep, its now drawing about 250uA. I quickly changed a few things to see if its something stupid I had done; like leave the debug interface on, wrong clocks or something, i even replaced the PSOC incase it had been an old chip which might have been slightly damaged, but no. I changed the 'SleepTimer_interrupt' example project to my board (simply connect the LED in the example to my LED) and ran it and got the same results -> 250uA. This was with a rather full battery (about 3.5V from a 3.6V lithium cell), so I thought to try other voltages. with my power supply if I give it 3.6V I get the same result, but when I crank it down to 3V the sleep current drops to 20uA??? I saw this response in both the example code and my own. Curiously this is still higher than I remember it being, so I'll do a bit of digging to find my old board and just verify my results.
Could it be that to truly get low power you need to provide an external 1.8V for the VCC lines? this is the only thing I can think of as the internal regulator is clearly still on during sleep.
Has anyone else experienced this?
- Labels:
-
PSoC 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Are you uising the boost regulator ? Curiously enough the currents you
are measuring are the Iq currents for boost reg in active and standby mode.
I am sure you have seen these ? (ap note has had revisions) -
http://www.cypress.com/?rID=64554 AN77900 - PSoC® 3 and PSoC 5LP Low-power Modes and Power Reduction Techniques
http://www.cypress.com/?rID=43337 AN61290 - PSoC® 3 and PSoC 5LP Hardware Design Considerations
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You changed some pins, as you said.
Can it be that now one of the pins supplies or draws current because it is not switched to Hi-Z before sleeping?
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, to spare everyone a long story, I did some more tests and it seems to come down to one pin (P15[1]).
I fetched my old board, and it drew even less current than I remembered: 1.5uA. there were only 2 capsense pins that changed, so I took the old code before the board update, loaded it on the new one and presto, the current was low again. I checked the toplevel hardware diagram, and only one thing changed; an idle pin that was left on the top sch in the old version. The reason I deleted it after the board update was that the pin name still refers to a function that was not implemented in the new board (I suspect this was actually an issue I experienced on the first board, as the first board was later modified to be like the new one, so that pin could have been removed).
The pin sch symbol sets up pin 15[1] as an output defaulting to high. This pin on the datasheet just says (GPIO, Xi), so I suppose its possible that the Xi function was being enabled by default or something.... always fun chasing these types of gremlins...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Congratulations to get it to work! Yes, that tiny little changes... always a source for spending some time to hunt them down...
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Xi is the Mhz Xtal Input pin, so its biased Class A I would posit, hence
draws a lot of current.
www.cypress.com/ AN54439
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thats possible, although I wouldn't think this is the case as my clocks are setup to use IMO from the start... unless the configuration of the pins are simply never chaned to refect this change in clocks. it would be interresting to go delve through the init code to see what happens with and without this... but for right now I'm just happy everything is working again.