DIY booster circuit causes Moteino resets

[EloyP]

Hello,

Resorting to the collective intelligence of the forum to try to get ideas and suggestions about an issue that I am seeing with a design involving a Moteino...

My application has a voltage booster that is controlled by the Moteino's I/O pins. The boosted voltage is stored in a capacitor. I use an I/O pin and a MOSFET to provide power to the voltage booster (to save battery) and another pin to cause the voltage to go up. The actual design is attached below.

The issue I am seeing is that sometimes when I enable the voltage booster, and the capacitor is initially discharged, the ATmega resets a few microseconds after turning on the voltage booster. I notice that it is no normal reset because the bootloader does not run; it's more like the ATmega jumps to address 0x0000, or some strange internal behavior, but that's for another topic...

What I am looking for is ideas of why this might be happening and how to prevent this from happening. Here's some supporting information:

The first oscilloscope screenshot shows the Moteino VIN (5V) and the Moteino 3.3V rail at the time of the event: VIN remains stable but there is a blip on the 3.3V signal that is apparently causing the ATmega to reset. It does not go below the brownout threshold (1.8V) and yet the ATmega goes down. So perhaps it is not voltage but current that is causing the problem, but I don't know how to capture this on the oscilloscope. I theorize too much current is being asked of the Moteino onboard MCP1703 voltage regulator and some built-in protection is kicking in.

The second oscilloscope screenshot shows the Moteino 3.3V rail *and* the Moteino D7 line, which is what controls power to the voltage booster. Note how D7 goes low and then it weirdly goes high -- that's when the ATmega resets. D7 should have stayed low.

My current theory is that when the capacitor is discharged and the voltage booster is enabled there is an inrush current from VCC, through Q11 and L1, and through C1 (which is a large capacitor). This upsets the MCP1703 and somehow causes the ATmega reset.

In terms of a possible workaround, I am currently testing this, which is the equivalent of a PWM that starts low and increases the cycle little by little:

Code Select Expand

    /*
     * Turn on the voltage booster. Don't turn it on all at once to try to prevent inrush current that will reset the MCU.
     */
    for (uint8_t i = 0; i < 10; i++) {
        digitalWrite(7, LOW); // Apply power.

        delayMicroseconds(i); // Keep voltage booster ON for "i" microseconds.

        digitalWrite(7, HIGH);  // Remove power.

        delayMicroseconds(10 - i);
    }

    digitalWrite(7, LOW); // Now leave power applied

This produces the third oscope screenshot and seems to be preventing the resets (currently testing in the field; not conclusive yet).

Ultimately, however, I think I will change the design to use VIN as the voltage to boost instead of VCC, i.e. Moteino VIN (and not VCC) will be the input to the voltage booster. This way the voltage to boost is not the output from the MCP1703. I think this will be a better solution but it requires that I insert a resistor between the two junctions on the IO3 line in the diagram below or else Q11 will not turn off (same discussion that took place with the WeatherShield and the transistor that feeds the battery monitor not turning off applies here).

Thanks in advance for any suggestions.

Cheers!

Eloy Paris.-

[Felix]

Probably rail collapse.
Why bother designing this charge pump yourself?
I would think it's too much hassle.

[TomWS]

Eloy,
a couple of observations:

1. You are correct in the conclusion that you should drive the boost circuit from Vin rather than from the MCP1703.  You may have gotten this idea from my schematic that shows everything running from the same pin as Moteino's 3.3V pin, however, the difference is that I remove the MCP1703 from the Moteino and 3.3V is an INPUT, not an OUTPUT.

2. Since you already have the circuit board wired as you do and apparently don't experience the reset until you fire off the solenoid, building up the charge into VBoost is not obviously exceeding the MCP1703 capacity.  Since the reset occurs during the firing of the solenoid, there are two plausible causes: 1. Current surge and that is going to be hard to track down.  I did look at your PCB and it's difficult to trace the ground paths, so nothing conclusive yet.  2. That you're essentially shorting out VCC through the inductor & Q11 when the solenoid is fired does explain the dip in voltage.  In this case, the simple solution is to turn off Q11 prior to firing the solenoid. You don't need this on at all once the CAP is fully charged. This should be done anyway but worth a try just to isolate whether its this or ground loop.

3. Don't try to 'PWM' the solenoid.  That is the way to madness...  And Q11 (IO7) isn't the way to do it anyway.

4. Finally, your 'Battery Monitor' circuit doesn't.  At least, until you move Q11 to the PWR net.

Good luck,
Tom

[EloyP]

Hi Tom,

Thanks for taking a look. A few quick comments...

Eloy,
a couple of observations:

1. You are correct in the conclusion that you should drive the boost circuit from Vin rather than from the MCP1703.  You may have gotten this idea from my schematic that shows everything running from the same pin as Moteino's 3.3V pin, however, the difference is that I remove the MCP1703 from the Moteino and 3.3V is an INPUT, not an OUTPUT.

No, I didn't get the idea to feed the voltage booster with VCC instead of VIN from your circuit -- my original design has the voltage booster fed from VIN (I updated the diagram that I attached so it reflects what I have on the PCB right now). It is just that I made a mistake when I drew the schematic and connected the source pin of Q11 to VCC instead of VIN, and of course that error propagated into the PCB. When the PCB came back the easiest way to "patch" the error was to cut a trace and connect the input voltage to the voltage booster to VCC. After all this mess and the issue with the ATmega resetting I now realize I should have left that connected to VIN and instead fix Q11 so its source is connected to VIN.

2. Since you already have the circuit board wired as you do and apparently don't experience the reset until you fire off the solenoid, building up the charge into VBoost is not obviously exceeding the MCP1703 capacity.

No no! The reset happens as soon as I turn on the voltage booster. Firing the solenoid never causes a reset, and that is to be expected because when I fire the solenoid Q11 is turned off.

Since the reset occurs during the firing of the solenoid, there are two plausible causes: 1. Current surge and that is going to be hard to track down.  I did look at your PCB and it's difficult to trace the ground paths, so nothing conclusive yet.  2. That you're essentially shorting out VCC through the inductor & Q11 when the solenoid is fired does explain the dip in voltage.  In this case, the simple solution is to turn off Q11 prior to firing the solenoid. You don't need this on at all once the CAP is fully charged. This should be done anyway but worth a try just to isolate whether its this or ground loop.

See above -- I *am* turning Q11 off prior to firing the solenoid; have always done it that way. There is no reset when firing the solenoid. The reset happens as soon as I turn on the voltage booster (and the big capacitor is discharged) and looong before I attempt to fire the solenoid. No reset happens when the capacitor has an initial charge (equal to VCC).

3. Don't try to 'PWM' the solenoid.  That is the way to madness...  And Q11 (IO7) isn't the way to do it anyway.

Right. I am not PWM'ing the solenoid; the H-bridge is turned off.

What I am "PWM'ing" with the hack I have in place is power to the voltage booster. And only for a few microseconds -- just enough to avoid the reset. Then I leave the voltage booster turned on.

4. Finally, your 'Battery Monitor' circuit doesn't.  At least, until you move Q11 to the PWR net.

Yes, I am aware -- it is just a consequence of my mistake when I drew the schematic: As I mentioned my goal was to feed the voltage booster with VIN so the battery monitor there is the perfect location. Now that I patched the circuit to feed the voltage booster with VCC instead of VIN then the battery monitor is not in the right location.

Thanks for taking a look and offering some suggestions. I think we are on the same page. What I will do is to hack the PCB one more time so I feed the voltage booster with VIN instead of VCC. As I said, that will require that I add one resistor so Q11 can turn off, but I do think that is the correct design. That should avoid the resets and prevent the need for my "PWM" hack (plus the battery monitor will work as initially designed).

Cheers,

Eloy Paris.-

[EloyP]

Here's an update on this issue...

I performed surgery on my PCB to do what I originally planned to do, i.e. feed the voltage booster from the same source that is feeding the Moteino voltage regulator (VIN) instead of from VCC (output from the voltage regulator), but that I could not do because of a mistake I made in the schematic.

The fixed design is shown below in the first attachment (in this schematic PWR is the same thing as Moteino's VIN). The astute reader will notice that the resistor values for the P-channel MOSFET are the same as those used by the WeatherShield for the P-channel MOSFET that turns on the battery monitor voltage divider; that is no coincidence as I read that discussion here on the forum. (Note: Small mistake in the schematic -- D7 and not D3 is what enables the voltage booster.)

The result is that now the Moteino does not reset (which is what I expected) when the voltage booster is enabled and the big capacitor is discharged.

However, there is still a blip, this time on the VIN rail instead of VCC. (See second attachment.)

Thinking about this, this blip makes sense, as does the blip (see attachment in my initial post) in the previous design (feeding voltage booster from output of Moteino voltage regulator, i.e. VCC) and the ATmega resets: This is an RC circuit with the resistor in series with the capacitor, where the resistor is actually the inductor. This RC circuit is documented thoroughly at https://en.wikipedia.org/wiki/RC_circuit#Series_circuit and the voltage on the resistor as a function of time is VR(t) = Vin x e^(-t/RC) so at time 0 the voltage across the resistor is VIN (5V in my current circuit, 3.3V in the previous circuit). If the inductor has a resistance of 10 Ohms then there are 0.5 Amps flowing at time zero. I think that explains the blip (and supports the theory that the Moteino voltage regulator cannot supply the inrush current because 3.3V/10 = 330 mA which is more than the max. of 250 mA of the MCP1703).

I think this (feeding the voltage booster from VIN) is a better design, as proven by the fact that there are no more resets. However, I am picky and I still do not like that there is a blip so I added my "PWM" hack, which basically has the effect of increasing the input voltage to the voltage booster little by little as opposed to supplying VIN all at once. This seems to be working well if I am to judge by what I see on the oscilloscope (see last attachment).

TomWS -- does this analysis make sense to you? Your voltage booster design and my voltage booster design are basically the same now (the only difference that I can tell is that I added an LED so the user can see when the voltage booster is on, and I added a voltage divider to monitor the batter), so I would expect your circuit to exhibit the same behavior. When you get a chance I'd love to see scope captures at the time you enable the voltage booster and the capacitor is discharged.

So I think this case is closed; thanks for the help!

Cheers,

Eloy Paris.-

P.S. I do notice that the big capacitor is getting charged to about 500 mVolts. This leads me to think that the P-channel MOSFET is not fully turning off. I guess I'll have to revisit the resistor values so the MOSFET fully turns off.

[EloyP]

Hi Felix,

Thanks for taking a look...

Probably rail collapse.
Why bother designing this charge pump yourself?
I would think it's too much hassle.

I agree it is probably rail collapse.

With regards to your question, let me try to answer it by quoting something you said before (on the WeatherShield low power thread):

"A dedicated battery monitor chip might be an alternative. But I'd have to do the research to pick one, cost might be magnitudes more, and the protocol to read it might be another learning barrier."

I would say the same thing about using an Integrated Circuit (IC) for my charge pump instead of building it out of discrete components :-)

On a more serious note, though -- I really didn't think about using an IC for this. Instead, one day I realized I needed a charge pump and built one out of components I had on hand and spare I/O pins on the ATmega. And I am glad I decided to do that because it has been fun and a great learning experience.

Things seem to be better now (see my previous post) so it does not look like a re-design is warranted, but if I do re-design I will look into using an IC instead of building the voltage booster out of discrete components. However, an IC still needs some, if not most of, the discrete components that I already have (inductor, protection diodes, voltage divider for feedback, filtering capacitors, big capacitor to charge, etc.) so in the end, for this particular situation, an IC might not save me much.

You are absolutely right in that it's a hassle to design something that one can buy off-the-shelf (for one, we have to develop software for it), but isn't that exactly what we do? There are off-the-shelf solutions to monitor mailboxes, garage doors, to control light switches wirelessly and from web pages, to control water valves, to monitor the weather, etc. and yet we build our own solutions because we think it is fun, because we learn, and because the off-the-shelf solutions don't work the way we want. So that's why I (sometimes) go through the hassle.

Sorry, I know I am preaching to the choir here but you asked :-)

Cheers!

Eloy Paris.-

[Felix]

Eloy, what about an LTC3525? It's very low power (quiescent), it has a SHUTDOWN pin. Needs 2-3 external components.
I use it on the PowerShield. Very stable and reliable.

[EloyP]

Hi Felix,

Eloy, what about an LTC3525? It's very low power (quiescent), it has a SHUTDOWN pin. Needs 2-3 external components.
I use it on the PowerShield. Very stable and reliable.

Thanks for the suggestion! I started to look at DC/DC converters the other day when you mentioned it but didn't see the LTC3525.

I does not look like the LTC3525 would work because I need to be able to go up to 24 VDC (the application is a DC solenoid-based water valve controller; similar to the project that TomWS has worked on, and that he shared here: https://lowpowerlab.com/forum/index.php/topic,1046.0.html), and the LTC3525 has fixed output voltages (3V, 3.3V or 5V).

But on a cursory look at available options on Mouser I saw some that are worth looking into. The only difference that I notice is that my discrete voltage booster allows me to set the output voltage in software, and these ICs all seem to have a fixed output voltage that is either pre-set inside the IC, or set with external components. This is not a deal breaker for my application as I can just shut down the IC once I reach the target voltage. (Hhhmm, so in essence, I guess it is the same thing if I turn on and off the IC -- the booster can be controlled in software as well. It'd have to be tested, but it's an interesting idea...)

Cheers,

Eloy Paris.-

[TomWS]

<snip>
TomWS -- does this analysis make sense to you? Your voltage booster design and my voltage booster design are basically the same now (the only difference that I can tell is that I added an LED so the user can see when the voltage booster is on, and I added a voltage divider to monitor the batter), so I would expect your circuit to exhibit the same behavior. When you get a chance I'd love to see scope captures at the time you enable the voltage booster and the capacitor is discharged.

My first question is what supply are you using for Vin in your tests?  It may be just PS recovery due to changing load.  However, I'm less inclined to worry about power blips on the Vin side of a regulator if its within your regulator's tolerance.

Regarding similarity with the circuit I published, the biggest difference is that, with my circuit, the Moteino power and Vin are the same supply so you don't have a level translation issue driving the gate of Q11. 

Re PWM hack, don't do it.  When you cut off the current to the inductor with Q11, where does the drain of Q11 go?  Probably well below ground would be my guess...  You would be far better off moving R9 to be in series with the inductor so that it current limits not only the current from the N channel transistor but also Q11.  Alternative (if you can drive Q11 fast enough) would be to add yet another schottky diode with the cathode to drain of Q11 and anode to ground.  At least then you are contributing to the charge at VBoost during the off cycle and limiting the voltage across Q11.  I say 'fast enough' because the current in the inductor builds up to saturation within 6 microseconds if I recall correctly (I don't have my scope files handy).

All that being said, it looks like you're well on your way to having a working system.  Congratulations and good perseverance!

Tom

[EloyP]

Hi Tom,

<snip>
TomWS -- does this analysis make sense to you? Your voltage booster design and my voltage booster design are basically the same now (the only difference that I can tell is that I added an LED so the user can see when the voltage booster is on, and I added a voltage divider to monitor the batter), so I would expect your circuit to exhibit the same behavior. When you get a chance I'd love to see scope captures at the time you enable the voltage booster and the capacitor is discharged.

My first question is what supply are you using for Vin in your tests?  It may be just PS recovery due to changing load.  However, I'm less inclined to worry about power blips on the Vin side of a regulator if its within your regulator's tolerance.

It's a wall wart. 5V/1A.

I think that is exactly what is happening, i.e. PS recovery due to changing load.

Yes, this blip on the Vin side of the regulator is not causing any problems.

Regarding similarity with the circuit I published, the biggest difference is that, with my circuit, the Moteino power and Vin are the same supply so you don't have a level translation issue driving the gate of Q11. 

Yes, that is a difference. However, I was thinking that that difference would not change how your circuit would in theory react to the case of big capacitor initially discharged when you turn on your voltage booster -- there should be an inrush current as well. I am curious to know so I'll just power my circuit from batteries and test again.

Re PWM hack, don't do it.  When you cut off the current to the inductor with Q11, where does the drain of Q11 go?  Probably well below ground would be my guess...  You would be far better off moving R9 to be in series with the inductor so that it current limits not only the current from the N channel transistor but also Q11.  Alternative (if you can drive Q11 fast enough) would be to add yet another schottky diode with the cathode to drain of Q11 and anode to ground.  At least then you are contributing to the charge at VBoost during the off cycle and limiting the voltage across Q11.  I say 'fast enough' because the current in the inductor builds up to saturation within 6 microseconds if I recall correctly (I don't have my scope files handy).

The PWM hack is so tempting because VIN looks so stable when I put the hack in place! :-)

Moving R9 also looks tempting although I'd have to test to see the impact on charging the big capacitor.

All that being said, it looks like you're well on your way to having a working system.  Congratulations and good perseverance!

Yes, I would think so, which makes me wonder if it is worth putting more effort into this just to achieve perfection when "good enough" will most likely do it.

Anyway, thanks for the great insight, as always.

Cheers!

Eloy Paris.-

[TomWS]

Eloy,
I think you're on the right track and its plausible that the blip is just PS recovery from the wall wart.

Moving R9 shouldn't change the charge characteristics too much as during 'pumping' the sum of that resistor and the inductor's resistor defines the current pumped into the capacitor.  That R9 would be used on both halves of the charge cycle would slightly affect the rise time of the charge but not the current.  It was a flaw in my initial design to have R9 where it is and, as you say, with the current R9 location, only the inductor's resistance limits the initial turn-on surge into the cap.  The main difference with my implementation was, while I might have gotten a dip, it doesn't bother the processor because it's from a low resistance source and there's plenty of head room on the processor voltage.  It should also be a relatively easy change to move R9 without any hacking of your PCB (other than standing the inductor on end...). 

You can mess with the PWM if you want, but to do so you NEED to add the extra diode and you really should switch to assembler and blast those first short pulses at a very high rate or, if you have a PWM output, you could drive the gate with a ramp starting at a very low duty cycle:

Code Select Expand

  byte i;
  for (i=1; i < 255; i++) 
  {
    analogWrite(pin, i);
    delayMicros(2000);  // leave plenty of time for 'off' time
  }

until the CAP is charged to Vin level.  Note that the PWM cycle is about 490Hz (125KHZ/255) so the initial pulse of 1t (8uS) is about right for the inductor.  The only problem with this is that it will take some 10s-100s milliseconds to build up the charge with analogWrite() approach while you could be more optimized in assembler.  Frankly, I'd just move R9 and declare success, but it would be a good learning vehicle to mess around with PWM techniques.

One other thing I didn't point out is that with the resistor divider on the gate to Q11, you will be constantly drawing current through the two resistors equal to about (Vin-~3.5V)/2500 even while sleeping.  You'll have to factor that into your battery life equation.

Finally, by all means try new stuff, that's how you learn!

Tom

[EloyP]

Hi Tom!

Excellent suggestions! I will definitely trying them. Moving R9 is the one that I will try right away (after work today). I am kicking myself for putting that resistor there -- my original design, which I shared here a couple of months ago:

https://lowpowerlab.com/forum/index.php/topic,1016.msg6749.html#msg6749

didn't have it but then I saw that your design had it and I thought "that's such a great idea; a current-limiting resistor! I'll do the same!" and put the resistor in without realizing that it would limit current only when one of the transistors turns on and not in all other cases. Well, you know what they say about hindsight...

A couple of additional comments (inline)...

Moving R9 shouldn't change the charge characteristics too much as during 'pumping' the sum of that resistor and the inductor's resistor defines the current pumped into the capacitor.  That R9 would be used on both halves of the charge cycle would slightly affect the rise time of the charge but not the current.  It was a flaw in my initial design to have R9 where it is and, as you say, with the current R9 location, only the inductor's resistance limits the initial turn-on surge into the cap.

Exactly!

It should also be a relatively easy change to move R9 without any hacking of your PCB (other than standing the inductor on end...). 

I've had to perform surgery on the PCB several times now so one more is not a problem :-) I do look forward to a new, clean PCB once I am done with all my changes.

You can mess with the PWM if you want, but to do so you NEED to add the extra diode and you really should switch to assembler and blast those first short pulses at a very high rate or, if you have a PWM output, you could drive the gate with a ramp starting at a very low duty cycle:

I don't have any PWM-capable pins available, unfortunately. However, I write my code in C and the generated code is very efficient based on what I am seeing in the listing file. In any case, I would prefer to go with the hardware solution (move the resistor to the right place) instead of adding more code (and that diode that you mention).

Frankly, I'd just move R9 and declare success, but it would be a good learning vehicle to mess around with PWM techniques.

Yes, yes! I'm all for easy (though not mediocre) :-)

One other thing I didn't point out is that with the resistor divider on the gate to Q11, you will be constantly drawing current through the two resistors equal to about (Vin-~3.5V)/2500 even while sleeping.  You'll have to factor that into your battery life equation.

Oh, yes, this voltage divider is the bane of our existence... It's the same one that the WeatherShield has. Yesterday I tried a 6V wall wart and the transistor didn't turn off with the resistor values I am using ("kind of" turns off with 5V but does not turn off with 6V).

Ironically, I *think* the root cause of this behavior is the protection diode on the I/O pin -- with that diode the maximum voltage at the pin will be VCC + 0.5V, which then requires a voltage divider so one can drive the transistor's gate from the midpoint of the divider. If we didn't have this protection diode then the voltage at the pin could go freely up to VIN (pulled up by resistor from gate to VIN) and the transistor would turn off flawlessly.

Finally, by all means try new stuff, that's how you learn!

Will do, thanks for the help! Totally agree!

Cheers,

Eloy Paris.-

[TomWS]

Ironically, I *think* the root cause of this behavior is the protection diode on the I/O pin -- with that diode the maximum voltage at the pin will be VCC + 0.5V, which then requires a voltage divider so one can drive the transistor's gate from the midpoint of the divider. If we didn't have this protection diode then the voltage at the pin could go freely up to VIN (pulled up by resistor from gate to VIN) and the transistor would turn off flawlessly.

There is nothing 'ironic' about it.  That diode keeps your nice low current ATmega328P from turning into one honking big SCR!  You exceed that voltage and you'd probably see the top of your device crackle and fry.

It's why you use level translators instead of resistors to drive voltages outside of the VDD/VSS range of the device.  Resistors are ok to drop external voltages down for input purposes, they're generally a bad idea as an output.

Tom

[EloyP]

Hi Tom,

Frankly, I'd just move R9 and declare success, but it would be a good learning vehicle to mess around with PWM techniques.

I followed your advice and moved R9 and now I will follow the second part of your advice -- declare success :-)

After moving R9 to be in series with the inductor I still see a little dip on VIN (output from the wall wart), but it is very small and I will not worry about it. I've attached a scope screenshot below. Green line is VIN (5V) and yellow line is D7, which turns on the voltage booster. There is no perceptible change in capacitor charging time or operation of the voltage booster.

I am not going to mess with PWM'ing anything as there really is no need for the additional complexity (the PWM hack was just an attempt to fix things in software but in reality, relocating R9 is a better design, as you suggest).

Attaching also what I think will be the final design of my voltage booster circuit.

Thanks a lot for all the suggestions and for bearing with me.

Cheers!

Eloy Paris.-