PIC12F1572 sleep current

[FrankBuss]

I did a simple project, a monoflop with a PIC:

https://hackaday.io/project/27471-monoflop

After some tweaking, like turning off the brown-out reset, which needed 2.8 uA, I managed to get it down to 6.4 uA for 3 V supply. The datasheet says 20 nA. Maybe this is for the LF part, not the F part, or just for some parts of the chip? But it shouldn't be that much higher. Does anyone have a working example, which needs the claimed 20 nA of the datasheet?

PS: I wrote to the microchip support two weeks ago, to give me an example with which I can reproduce the 20 nA, but no answer at all so far. Maybe I should switch to a MSP430, if they are better for such applications.

[Bruce Abbott]

You have the F part, not LF? Then it will be much higher than 20nA.

Maybe I should switch to a MSP430, if they are better for such applications.

What applications need such low current?

[funkathustra]

According to Table 26-3, the LF version hits 20 nA at 1.8V, and 25 nA at 3V. But the high-voltage "F" version that you're using only goes down to 300 nA at 3V.

First steps: you didn't post a schematic and PCB layout for your design. Can you show us what your actual circuit is?

I don't know your background, but a lot of hobbysts/makers don't use correct decoupling strategies when prototyping their projects. While these parts tend to work ok without correct decoupling, they'll use much more power than they're supposed to in sleep mode --- I've seen parts use ten times more power in sleep mode when the decoupling caps are removed.

Next, it looks like your code has pull-ups enabled, which can draw significant current. While the PIC12 datasheet doesn't seem to indicate there's much current pulled, you may want to disable pull-ups and manually tie the pin to a state. Input leakage current doesn't look particularly high on the PIC12, but that will affect things.

It's good to see you setting all unused pins as outputs. Does it matter if you set them to drive high versus low? It's usually recommended to drive unused pins low (probably due to the N-FET leaking less than the P-FET on the output? idk)

Doesn't that PIC have a 32 kHz oscillator? Is there a reason you're using such a fast clock?

Is the FVR disabled?

[cv007]

You will see a (relatively) big difference LF vs F.

it seems you are using MCLR as an input (according to fuses), since it is only an input, unless you have a pullup/pulldown connected, it is a floating input (simple fix to test- just enable internal pullup on RA3)

anything hanging on the pins, like a scope probe, programmer, etc., may effect the readings (easily overlooked)

[Kalvin]

Check the I/O pins that they are not floating. Move your finger across the pins and observe any change in the power consumption.

[mikeselectricstuff]

Check the I/O pins that they are not floating. Move your finger across the pins and observe any change in the power consumption.

+1 - very useful test for floating pins. In particular that the current is different before vs. after touching.

[FrankBuss]

I bought some PIC12LF1572 and did a clean test setup. My previous setup was in a circuit with some LEDs, which were turned off, but maybe there was some leakage. It gets really tricky if you want to measure nanoamps.

This is the new setup, on a SMD breakout board and carefully cleaned after soldering, but not on a breadboard to avoid any additional leakage or noise (sometimes I measured less current when on a breadboard, which is strange). It is only the microcontroller and a 100 nF capacitor between VSS and VDD:



I updated the Hackaday project with the new source code and full MPLAB-X project:

https://hackaday.io/project/27471-monoflop

I didn't change much, except removing the VREGCON access, which is not available for the LF version, and enabling the internal pullup on MCLR (which I configured as digital input), thanks for the tip. Without this pullup, it needed sometimes more current, when I touched it with my finger. Measured current in sleep mode at 1.8 V is now 11.9 nA. That's awesome and better than the datasheet claims! When running at the lowest internal frequency of 31 kHz, which is sufficient for the monoflop function, it needs about 2.5 uA. My measurement setup is a uCurrent (with an additional 100 nF at the inputs, because it can oscillate) and a BM257s in DC mV mode. I don't know how accurate the measurements are, but should be ok, because I verified it with a 9.5 megohm resistor and it was right, 188 mV at 1.8 V in the nanoamp range.

There is one remaining problem: I tried to use RA3 as the interrupt on change (IOC) source, but this didn't work. And debugging was not possible, because this needs MCLR enabled as reset input. I think I configured anything as required, which is LVP off, otherwise the MCLRE config bit is ignored says the datasheet, so it should be a digital input pin. Have to do some more tests with it.

And finally I will do the same clean setup and test with a PIC12F1572, to check how much power this needs.

Conclusion: For this simple real world application of a monoflop, and similar applications for replacing old logic gates, a PIC12LF1572 is perfect, if it doesn't need to be too fast. And it needs much less power than conventional monoflops. For example a 74HC123 needs 8 uA quiescent current. Other logic functions, like a NAND gate, could be implemented in an energy-saving way with interrupts and sleep as well.

[Howardlong]

11.9nA is pretty impressive, especially for it to actually do something!

One problem I found when working on some ultra low power stuff a year or so ago was that the specs in the datasheets often lack complete information of the conditions under which you can achieve such low power.

Certainly cleaning boards thoroughly helps, and I haven't found a chemical-only solution, and it gets worse the finer the pitch. I find I have to use an ultrasonic bath if I am to stand a chance of approaching manufacturer claims.

Measuring current is another problem, especially when you have a large dynamic range: it's not difficult for there to be a 10,000:1 or more difference between active and sleep, and tiny duty cycles of similar scales. Finding average current in such circumstances means using integration techniques, in my case a simple RC worked well. The uCurrent is good for measuring low currents that don't peak: when the MCU comes out of standby, it's too easy to saturate and give you lower aggregate readings that you really have.

FWIW, here was one of my projects, where I attempted to build a clock running at less than 1uA. I was in the right ball park, but I didn't achieve 1uA, it was about 1.8uA, perhaps I could've succeeded with a smaller display (less capacitance). Certainly it'd be feasible if I dropped to a four digit display HH:MM as not only are there fewer segments, there would be less for the MCU to do. https://www.eevblog.com/forum/projects/happy-nerd-year!-my-first-project-of-the-year-semi-fail/

[Kalvin]

If the device has a determined behavior pattern, one can measure the current in the sleep state and active state separately. Placing a diode across the multimeter's current measurement input makes measuring low currents a bit easier if the device can wake up intermittently. The diode will limit the burden voltage drop across the shut resistor and the device may be able to operate properly even with a multimeter with larger burden voltage. Check the diode leakage current, though. Check also the upper current limit the diode setup provides still correct result as the multimeter will show lower than the actual current at higher current levels as the diode starts conducting and bypassing the current. Sometimes placing two multimeters in series is handy: The other is set to 1A or 10A range in order to minimize the burden voltage and the other is bypassed with a diode in order to be able to measure sleep mode current.

[Howardlong]

If the device has a determined behavior pattern, one can measure the current in the sleep state and active state separately. Placing a diode across the multimeter's current measurement input makes measuring low currents a bit easier if the device can wake up intermittently. The diode will limit the burden voltage drop across the shut resistor and the device may be able to operate properly even with a multimeter with larger burden voltage. Check the diode leakage current, though. Check also the upper current limit the diode setup provides still correct result as the multimeter will show lower than the actual current at higher current levels as the diode starts conducting and bypassing the current. Sometimes placing two multimeters in series is handy: The other is set to 1A or 10A range in order to minimize the burden voltage and the other is bypassed with a diode in order to be able to measure sleep mode current.

Interesting, but I feel like I am missing something. How does this work if the MCU is going in and out of sleep at, say, 10Hz? How is the meter with the diode measuring the sleep mode current alone? And how is the high current meter measuring the very low duty cycle active current?

The way I did it was to measure the two modes separately in steady state, with a couple of code mods, and then correlate that with the integrated RC result measuring the mean duty cycle.

[Kalvin]

If the device has a determined behavior pattern, one can measure the current in the sleep state and active state separately. Placing a diode across the multimeter's current measurement input makes measuring low currents a bit easier if the device can wake up intermittently. The diode will limit the burden voltage drop across the shut resistor and the device may be able to operate properly even with a multimeter with larger burden voltage. Check the diode leakage current, though. Check also the upper current limit the diode setup provides still correct result as the multimeter will show lower than the actual current at higher current levels as the diode starts conducting and bypassing the current. Sometimes placing two multimeters in series is handy: The other is set to 1A or 10A range in order to minimize the burden voltage and the other is bypassed with a diode in order to be able to measure sleep mode current.

Interesting, but I feel like I am missing something. How does this work if the MCU is going in and out of sleep at, say, 10Hz? How is the meter with the diode measuring the sleep mode current alone? And how is the high current meter measuring the very low duty cycle active current?

The way I did it was to measure the two modes separately in steady state, with a couple of code mods, and then correlate that with the integrated RC result measuring the mean duty cycle.

There are some limitations like you pointed out when using simple instruments and production code. As you wrote, preparing a firmware which will stay in a predetermined state through out  the measurement is a simple solution. Then, measuring the duty cycle of the device operation (for example monitoring the device state with an oscilloscope) one could compute the energy consumption accurately.

[Howardlong]

If the device has a determined behavior pattern, one can measure the current in the sleep state and active state separately. Placing a diode across the multimeter's current measurement input makes measuring low currents a bit easier if the device can wake up intermittently. The diode will limit the burden voltage drop across the shut resistor and the device may be able to operate properly even with a multimeter with larger burden voltage. Check the diode leakage current, though. Check also the upper current limit the diode setup provides still correct result as the multimeter will show lower than the actual current at higher current levels as the diode starts conducting and bypassing the current. Sometimes placing two multimeters in series is handy: The other is set to 1A or 10A range in order to minimize the burden voltage and the other is bypassed with a diode in order to be able to measure sleep mode current.

Interesting, but I feel like I am missing something. How does this work if the MCU is going in and out of sleep at, say, 10Hz? How is the meter with the diode measuring the sleep mode current alone? And how is the high current meter measuring the very low duty cycle active current?

The way I did it was to measure the two modes separately in steady state, with a couple of code mods, and then correlate that with the integrated RC result measuring the mean duty cycle.

There are some limitations like you pointed out when using simple instruments and production code. As you wrote, preparing a firmware which will stay in a predetermined state through out  the measurement is a simple solution. Then, measuring the duty cycle of the device operation (for example monitoring the device state with an oscilloscope) one could compute the energy consumption accurately.

Indeed.

Even a 10Mohm scope probe loading dramatically affects results at these current levels ;-)

Still, you can at least model that out.

[Kalvin]

If the device has a determined behavior pattern, one can measure the current in the sleep state and active state separately. Placing a diode across the multimeter's current measurement input makes measuring low currents a bit easier if the device can wake up intermittently. The diode will limit the burden voltage drop across the shut resistor and the device may be able to operate properly even with a multimeter with larger burden voltage. Check the diode leakage current, though. Check also the upper current limit the diode setup provides still correct result as the multimeter will show lower than the actual current at higher current levels as the diode starts conducting and bypassing the current. Sometimes placing two multimeters in series is handy: The other is set to 1A or 10A range in order to minimize the burden voltage and the other is bypassed with a diode in order to be able to measure sleep mode current.

Interesting, but I feel like I am missing something. How does this work if the MCU is going in and out of sleep at, say, 10Hz? How is the meter with the diode measuring the sleep mode current alone? And how is the high current meter measuring the very low duty cycle active current?

The way I did it was to measure the two modes separately in steady state, with a couple of code mods, and then correlate that with the integrated RC result measuring the mean duty cycle.

There are some limitations like you pointed out when using simple instruments and production code. As you wrote, preparing a firmware which will stay in a predetermined state through out  the measurement is a simple solution. Then, measuring the duty cycle of the device operation (for example monitoring the device state with an oscilloscope) one could compute the energy consumption accurately.

Indeed.

Even a 10Mohm scope probe loading dramatically affects results at these current levels ;-)

Still, you can at least model that out.

Well, it all depends on how you do it. If you drive the pin high when the device is in high current state and drive pin low when in sleep state, the 10Mohm loading will not affect the reading. Alternatively, you can place the scope across the shunt resistor if the device is floating without affecting the device current. There are quite a few ways how to do the measurements.

[Howardlong]

For the avoidance of doubt, my point was that you need to be aware of it. You can see the level of detail I go into in the video in the link I posted.

The OP has done a great job.

[FrankBuss]

Just to verify the results, I used my Fluke 8842A (which is nice for this application, because it has >10 Gohm input resistance for the 20 V range) and the charged 100 nF decoupling capacitor. I used the Raspberry Pi2/3 logging platform for Voltnuts and this script. The raw data is here. This is the curve:



Looks interesting, a constant current discharge, but then a discontinuity at about 1 V. I guess this is when the microcontroller stops working.

At 3 V and 100 nF, the stored energy in the capacitor is 450 nJ. At 1 V it is 50 nJ. It needed 137 seconds to use 400 nJ. So it needed only 3 nW average? This would result in only 1.5 nA at 2 V. Either this is wrong or my last uCurrent measurement was wrong. I verified the capacitor and it is 98 nF. Any idea how to check the real current consumption?

[Kalvin]

For the avoidance of doubt, my point was that you need to be aware of it. You can see the level of detail I go into in the video in the link I posted.

The OP has done a great job.

Incidentally I have also used the PIC24F XLP controller three years ago in a micropower design. It was quite easy to get the device in to the 50nA range when the I/O-pins were configured as output and driven to low state (they were driving the MOSFETs used for the controlling power domains etc.) and the device was in deep sleep mode doing nothing but waiting for an external interrupt. Enabling the RTCC using external 32.768kHz xtal increased current consumption to 500nA+, I do not recall the hairy details too well any more. The oscillator was very sensitive to the loading capacitance as the power consumption increased quite significantly (even up to few microamperes) if the wrong valued capacitors were used. The xtal itself had to be suitable for the nanoampere use. So, I suggest to check the external xtal and capacitors along with the GPIO if the power consumption is too high. Enabling brown out reset circuitry etc. increased power consumption significantly.

[Kalvin]

Just to verify the results, I used my Fluke 8842A (which is nice for this application, because it has >10 Gohm input resistance for the 20 V range) and the charged 100 nF decoupling capacitor. I used the Raspberry Pi2/3 logging platform for Voltnuts and this script. The raw data is here. This is the curve:



Looks interesting, a constant current discharge, but then a discontinuity at about 1 V. I guess this is when the microcontroller stops working.

At 3 V and 100 nF, the stored energy in the capacitor is 450 nJ. At 1 V it is 50 nJ. It needed 137 seconds to use 400 nJ. So it needed only 3 nW average? This would result in only 1.5 nA at 2 V. Either this is wrong or my last uCurrent measurement was wrong. I verified the capacitor and it is 98 nF. Any idea how to check the real current consumption?

You results matches with the calculations: dV = i * t / C, which gives i = dV * C / t = 1.36nA. If you have a large resistor (100 Mohm, for example) you could try that with the capacitor and see if it matches with your measurements after you take into account the Fluke 8842A.

[Kalvin]

You may have another DMM which has input impedance of 10Mohm which would give you 10 mV / nA.

[cv007]

Maybe you already know this, but

There is one remaining problem: I tried to use RA3 as the interrupt on change (IOC) source, but this didn't work

If you are setting the config as shown on the hackaday page (although in your post you say lvp is off)-
#pragma config MCLRE = OFF
#pragma config LVP = ON
then you will not get RA3 to work as an input, as LVP overrides MCLRE when set to ON.

LVP ON = MCLR cannot be used as input, weak pullup is enabled (MCLR functioning as MCLR)
LVP OFF = MCLRE fuse in effect (either MCLR as MCLR if ON, or as RA3 input with weak pullup controlled by WPUA3 if OFF)

[FrankBuss]

Ok, found the problem with the capacitor measurement: My Fluke 8842A behaves as if it has an input capacitor of about 650 nF for VDC (I tested it with a 100 megohm resistor, built with 10 x 10 megohm resistors I had here, without an external capacitor and it needs about 72 seconds to discharge from 3 V to 1 V). When I try to measure the capacitance with another DMM, it shows only 0.1 nF and I can't find the input capacitance specification in the manual, only for AC, which is much lower.

With the additional 100 nF external capacitor, the last measurement makes sense: At 3 V and 750 nF, the stored energy in the capacitor is 3.375 uJ. At 1 V it is 375 nJ. And it needed 137 seconds to use the 3 uJ difference. So it needed only 22 nW average. This would result in about 11 nA at 2 V, which matches my uCurrent measurement very well. So I'm confident now that the PIC12LF1572 needs about 12 nA in sleep mode when nothing else is running or activated, except for an interrupt on change pin. Sorry for reading all the blabla of an analog noob like me I guess the Fluke has such a high input capacitance for higher precision in DC mode?

[Howardlong]

For the avoidance of doubt, my point was that you need to be aware of it. You can see the level of detail I go into in the video in the link I posted.

The OP has done a great job.

Incidentally I have also used the PIC24F XLP controller three years ago in a micropower design. It was quite easy to get the device in to the 50nA range when the I/O-pins were configured as output and driven to low state (they were driving the MOSFETs used for the controlling power domains etc.) and the device was in deep sleep mode doing nothing but waiting for an external interrupt. Enabling the RTCC using external 32.768kHz xtal increased current consumption to 500nA+, I do not recall the hairy details too well any more. The oscillator was very sensitive to the loading capacitance as the power consumption increased quite significantly (even up to few microamperes) if the wrong valued capacitors were used. The xtal itself had to be suitable for the nanoampere use. So, I suggest to check the external xtal and capacitors along with the GPIO if the power consumption is too high. Enabling brown out reset circuitry etc. increased power consumption significantly.

Thanks, but all your suggestions were already done and checked I’m afraid, as the video and thread I mentioned explain. Getting thr RTCC to even work off the xtal was a chore, you have to be really careful of the specifications, and they can be quite slow to start.

By far the biggest surprise was cleaning the board in an ultrasonic bath.