First Prototype DC-DC Converter

A project log for Coin Cell Jump Starter

Starting a car with a CR2477 coin cell

Ted YapoTed Yapo 12/07/2017 at 15:109 Comments

I wired up a first prototype converter last night and coded up a quick test this morning.  So far, it "works," but not great.

The converter is based around a PIC12LF1571 that drives a simple MOSFET/inductor/diode circuit.  Here's the schematic:

The PIC code (attached at the end of this log) generates a 17us pulse every 94us to magnetize the inductor by switching on the MOSFET.  When the magnetic field decays in the coil, the voltage rises to maintain the same current flow, charging C1 through the Schottky diode.

I chose this topology because I had better NMOS transistors in stock than PMOS. I first saw the IRLML6244 when @Elliot Williams used it in his version of #TritiLED, and it has quickly become one of my go-to parts.  I might end up substituting something else later, but for now, this seems fine.  Two output pins from the PIC are paralleled to increase the drive current and promote faster switching in the FET.

I originally modeled the circuit with a BAT54 diode, because everyone has a million of them, but the 1N5817 is more efficient in this circuit due to the large current pulses.  The downside to the 1N5817 is the larger reverse leakage (up to 500uA, even 1mA at 20V on some datasheets).  Quick estimates make it more efficient, but I'll have to examine this in more detail.

I wanted a low-ESR capacitor, and the best I could come up with was 10x 10uF 1206 ceramic caps in parallel.  I'll probably add another few hundred uF of low-ESR polymer caps when I find the missing bag of them around here.  This large capacitance averages out the current drawn from the cell so that it doesn't see the hundreds of mA drawn by the inductor during the pulses. There are some other miscellaneous bypass caps on the board, but they probably don't do anything interesting :-)

I didn't have any beefy inductors of around 100uH in the junk box, so I hand-wound one on a core salvaged from an old power supply.  Nearest I can figure, the core is a T131-26 (yellow/white paint).  I wound 35 turns of 20AWG wire on there, which ends up measuring out to 115uH, as predicted by the formulas (113.9).

I've only had a chance to test the converter briefly, and so far it "works," charging a 10F capacitor to 1V in a little less than 2 minutes, while drawing 43mA from a CR2032.  A quick calculation shows that this is 15.5J out of the cell, with 5J stored in the capacitor for an efficiency of around 33%.  I need to at least double that to hit my goal of 67F charged to 14V.  In the circuit's defense, I didn't precisely time the charging, so the measurement might be off.  Another possibility is that my 10F capacitor is more than 10F.  It came from the junk box, and isn't marked with a tolerance, so who knows.

Next, I need to instrument the circuit to see what's going on - I'll add a 0.1-ohm resistor in series with the inductor so I can see the current waveforms, which will probably be the most interesting.

I also need to add an over-voltage crowbar to the output.  With the 67F capacitor, there probably won't be any danger of over-charging, but the smaller capacitors I have to play with for now could easily be damaged by a few minutes of inattention.  My plan is to add an adjustable shunt regulator, a TL431, directly across the output.  The power output of the converter is low enough so that the TL431 can just dissipate it all once the target voltage has been reached.

Here's the trivial code running on the PIC:

;;; coin_cell_cap_charger.asm: DC-DC converter for charging supercapacitors
;;;                            from coin cells
;;; Copyright (C) 2017 Theodore C. Yapo
;;; Licensed under MIT license (see file)

    LIST        P=12LF1571
 #include    <>


;;; I/O pin configuration
GATE_DRIVE_A  equ   4
GATE_DRIVE_B  equ   5


;;; variables in Common RAM (accessable from all banks)
  CBLOCK 0x70

  ORG     0
  movlw     .255
  movwf     reset_counter

  movlw     b'00000000'     ; all digital I/O
  movwf     ANSELA

  clrf      LATA

  ;; set gate driver lines as output
  movlw     ((0xff ^ (1 << GATE_DRIVE_A)) ^ (1 << GATE_DRIVE_B))
  movwf     TRISA

  movlw     b'01101010'      ; 4 MHz HF osc
  movwf     OSCCON

  movlw     (1 << GATE_DRIVE_A) | (1 << GATE_DRIVE_B)  
  movwf     LATA              ;start inductor ramp-up
  clrf      LATA              ;end inductor ramp-up
  movlw     .26
  call      DELAY_3W
  decfsz    reset_counter
  goto      MAIN_LOOP

;;; delay 3x value in W (W must be >= 3; minimum 9 cycle delay)
  addlw     -.2
  movwf     delay_counter
  decfsz    delay_counter
  bra       DELAY_3W_LOOP
  ;; fill remainder of program memory with reset instructions
  fill      (reset), 0x0400-$-2



David H Haffner Sr wrote 12/08/2017 at 17:19 point

Hey Ted, man, you are always doing something wild and woolly :)

  Are you sure? yes | no

Ted Yapo wrote 12/08/2017 at 20:12 point

I just couldn't pass this up.  I'll either get it to work, learn a lot of stuff, or both.  Any of the above is fine with me.  Somebody had to give it a shot, though...I mean the gauntlet was thrown down right in the contest announcement blog post.  Could we, the HaDio community, let that go unanswered??

  Are you sure? yes | no

David H Haffner Sr wrote 12/08/2017 at 20:34 point

No I guess not my man :)

  Are you sure? yes | no

jaromir.sukuba wrote 12/07/2017 at 20:33 point

You get worse efficiency also because of supercap self-discharge. Did you actually measure it? Schottky leakage will cause additional discharge, both the effects are relatively easy to measure with voltmeter and stopwatch.

  Are you sure? yes | no

Ted Yapo wrote 12/07/2017 at 21:34 point

That's a good point.  I haven't measured it accurately, but noticed that the capacitor voltage drops pretty slowly with the power to the converter disconnected (so, including the cap self-discharge and diode leakage).  Just by the look of it, I guess it's not where the bulk of the loss is.

But you are right, it's easy to measure, and definitely good to know.  I'll measure more accurately and try to account for where all the energy is going.

  Are you sure? yes | no

Jan wrote 12/07/2017 at 18:47 point

Dude, posting assembly code is like a DRM protection for us arduino fiddlers :P
Anyway what came to my mind is: Switching a MOSFET at such high frequencies might need a charge pump because of the gate capacitance?! I think there are logic level MOSFETS with much lower Rds(on) values like the IRLR8743 which has 0,003R instead of 0,021R plus extremely low gate capacitance.

I guess when using a coin cell power loss is number one priority, right? :)

  Are you sure? yes | no

Ted Yapo wrote 12/07/2017 at 19:16 point

I can't read PIC assembly either; only write it.  I posted the code only in the spirit of "open source" to meet the letter of the contest rules.  The posted code is simply a 555 timer where you don't have to go searching through a big box of crap for the correct resistors :-)

The total gate charge on the IRLML6244 is 8.9nc, with two paralleled I/O pins, I'm guessing it switches relatively fast - but I haven't been able to see the waveforms yet. The 27mOhm Rds (at 2.5V Vgs) doesn't bother me that much for now - but it's somewhere to look once I figure out where the bulk of the loss is.  But at 2V Vgs, the Rds really does increase according to the datasheet.

I didn't measure exactly, but there's about 3 feet of wire on the inductor - for 20AWG wire, that's around 30mOhms right there.  I also assume with such a large toroid that the core losses would be minimal, but I might be better off with a commercial inductor - the manufacturers presumably know what they're doing.

I actually suspect the Schottky.  I have been thinking about an active rectifier solution, but haven't proven the need to go there yet.

First thing I need to do is check out some waveforms to see what the heck is going on in there.

Thanks for the tip on the IRLR8743; I will check it out.

  Are you sure? yes | no

jaromir.sukuba wrote 12/07/2017 at 21:30 point

The code is just fine to read and follow.

Why do you reset the PIC after every 256 loop cycles? To prevent from lock-up state holding transistor open? Watchdog timer could be better solution here.

  Are you sure? yes | no

Ted Yapo wrote 12/07/2017 at 21:38 point

@jaromir.sukuba  Yes, the reset is just a hold-over from the TritiLED code I started with.  The original idea was to correct any RAM corruption that might happen over the course of years (cosmic ray, etc).  In this case, I thought it might help with brownout issues near the end of life, so I just left it in.

There are probably better solutions - like maybe the actual brownout reset on the PIC - but I haven't thought it all through very well, yet.

  Are you sure? yes | no