BTW, Silab’s application note AN45 states that the MOSFET+transformer edition of the converter is preferrable for low values of VUNREG, but of course I am that type of excellent engineer who likes to first design, then build, and finally read the application notes (I trust you ‘ve met guys like me before — or, still worse, you are the exact same kind of engineer — so you know exactly what I am referring to…). Thus now I had two choices: either debug my board, or re-design it from scratch using the MOSFET version (which also sounds more expensive, so it defeats my initial $10 purpose…). Of course, I chose the first option! But let me take things in turn.
My first bug proved easy to spot. A difference in the voltages of the two sense pins of the 3210, SDCH and SDCL, drove me into spotting a bad “via” (actually, this had been corrected before my previous post, or else the converter would have never worked in the first place, not even intermittedly).
Then, I started exploring my way, starting from the 3210, and testing owards, with L1 as my final destination. Let me begin by introducing the schematic of the BJT version of DC-DC converter, copied from si3210’s datasheet:
From the few things I understand about electronics, this is how the thing works: the chip drives the converter through DCDRV (a square pulse signal, with frequency and duty cycle as configured using the chip’s control registers). When a logical “1” appears on DCDRV, Q8 is driven into saturation, which then causes a current of (VUNREG — VCE)/(R16+R17) to pass through Q8, where VCE is the voltage drop between Q8’s collector and emitter (VUNREG is shown as VDC on this version of the schematic). With current values of R16 and R17, this should cause a voltage in the order of VUNREG–1V to be applied to Q7’s base, driving in turn Q7 into saturation. Then, current flows through Q7, “charging” L1 with energy; then, when DCDRV is switched to logical “0”, Q8 and Q7 stop conducting, and L1 discharges through D1. This negative current is “stored” in C9, which also normalizes the “spiky” voltage produced by L1 discharge, producing the output voltage VBAT (-65V in our case). Should be as simple as that…
However, there are two more things to discuss: one is the DCFF signal which connects to Q7’s base through C10. What does this do? In our version of si3210, the DCFF pin produces the same signal as DCDRV inverted; this signal, fed through C10 to Q7’s base, increases the converter’s efficiency by compensating for the capacitive load of Q8 and thus making Q8 switch off faster (as per AN45, “the capacitor, C10, provides additional charge pump boost current from the DCFF pin of the Si321x to turn Q7 off faster”). Still as per AN45, “C10 with a value of 22 nF is sufficient for most applications” (AN45, p.5), however, as you can witnesss yourself, the example converter schematic from the si3210 datasheet shows a value of 100nF for this same C10.
The next thing to discuss is the voltage and current feedback circuitry, which allows si3210 to monitor the status of the converter and its output VBAT voltage. However, I’ ll discuss this a bit later.
I first debugged the signals around Q8 and Q7. Because of the unexpected behavior that I saw around Q7 though, (see oscilloscope shots later on), I first suspected that the ratio of the resistors R16 and R17 was inadequate to drive Q7 into saturation. Thus, I experimented with various values (soldering resistors in parallel or replacing existing ones), with limited success. For example, I tried R17=426Ohms (instead of its nominal 450Ohms value), and R16=220Ohms (instead of 200). By “limited success”, I mean that in my first experiment (R17=426Ohms), the si3210 occassionally did monitor some current flowing through Q7 and Q8 in its respective registers, however register 82 seldom did show something (and, when it did, it showed a much larger value than expected, around -90V — something that led the chip to quickly turn off the converter in order to protect it from burning). The second experiment, with R16=220Ohms, did not result in any remarkable result: the converter never made it to work with this resistor value; however, on the positive side, the chip was not sensing any overflow, so it did not reset the converter, and now I had a steadier condition to debug (observation of the circuit’s behavior through converter reset sequences was hard, because it involved transient behavior with much guesswork on when, why, and for how long some signals were changing or disappearing altogether).
So now I measured the various signals using an oscilloscope (from a video repair lab in my daytime job, whose employees I have to thank for tolerating me so many hours). In the pictures below you can see the interesting results.
Here are the two PCM bus signals, PCLK and FSYNC. They are not shown in the same time scale, for I wanted to show that PCLK has a duty cycle less than 50% (remember a 5-PIC-cycle bug that I need to correct in my TIMR1 code?), for which I needed just a few PCLK cycles to appear on the screen, whereas the FSYNC pulse is sparse (one pulse every 64 PCLK’s) to fit in the same time scale. BTW, can you see the actual FSYNC pulse? It’s just a small “spike” on the left of the screen.
The PCLK and FSYNC signals have nothing really to do with my debugging the DC-DC converter; I just thought it would be nice to show them (plus, I wanted to be sure that the 3210 is driven correctly. So, back to the DC-DC converter now.
The image on the right shows the output of the DCDRV pin, fed into the base of Q8. The frequency is something near 80kHz, and the duty cycle is as set in 3210’s control registers. So, everything is fine there, let us move on.
This image on the right shows what is happening at the emitter of Q8, right above R17 (the time scale is not the same as in the previous picture, so do not worry about this). As Q8 is switching on and off, current flows on and off through R17, so a pulse is generated at Q8’s emitter. However, there is something worrisome: the height of the pulse seems to be 5V (the viewing scale on the scope is 2V per div). According to my analysis above, this should be R16 x (VUNREG–VCE)/(R16+R17), which yields something in the order of 3 to 3.5V; well, if this is 5V, then what the heck is happening at Q8’s collector? Let us see right away…
Wow, what’s that? Looks like something oscillating very quickly (the oscilloscope cannot really display a visible oscillating signal in any time scale) from 5 to 6V! Where did the additional 1V come from? The only possible explanation is the DCFF signal. But how come this signal adds up to 6V? A possible explanation could be that some inductance is introduced in series with C10 from some badly designed copper path on my PCB, acting as a small DC-DC up-converter. How could I verify this? But, before going on with debugging, I thought I ‘d measure the output of Q7. The result is shown below.
This is pretty damn interesting, don’t you agree? But I have not the slightest idea what it means. My next step was then to remove C10 altogether, so that the DCFF signal is disconnected. Allegedly this signal is there only to “help Q8 switch off faster”. So, I thought I ‘d let Q8 “helpless” for a while. As soon as I did that, I measured -65V at the anode of D1! However, I did the change at home, and I need to scope again the board to show pictures of what changed in the converter’s signals.
Why could this be happening? I do not really know, but I have two plausible explanations. First, the DC-DC converter is designed for VUNREG>VDDD, which means that the pulses around Q8 would be something around 10V, whereas the DCFF signal would be 3.3 or 5V, so it would introduce a small 0,5-1V jitter, not that important as in my case. Second, as I said before, it may be a bad PCB design (yes, I checked C10 and found it OK). Or, it could be that I need a lower-value capacitor for C10. Or, I may need to add a low-value capacitor in the order of 10pF between Q8’s collector and the signal ground, to create a low-pass filter that would eliminate high frequencies apparently introduced there. We ‘ll see. For the time, I am happy with Q7 working without DCFF’s “help” (although it gets somewhat hot, it seems to still work within its temperature limits without burning).
Moreover, this was not the end of my pains: although the converter is producing -65V, the 3210 still does not measure anything in register 82. Why? Probably this is a bug in the values of R28 and R29 (you have to consult my schematic to see these). I have to debug this further, plus I have to measure the signals anew with the oscilloscope. Well, had I known all this beforehand, I would have never started with this project. But now I am midway through, and it would be a cowardly action to give up, wouldn’t it? So, let’s move with debugging! Hang on, brave readers, probably this adventure will eventually come to an end!
Update shortly after the post: thanks to Klaus, who provided this valuable comment, I quickly found why the 3210 was not sensing the -65V. The cause was a bad “via” right next to R5. I had checked all “vias” one by one, but this one probably was a bad contact working on occasion, or else I would have never observed 65V before through the chip’s sense. Anyway, this is a big relief. Thanks a lot, Klaus!! This was really valuable help!
Update, March 20 2009: I tested soldering C10 back in. It turned out that there is nothing wrong with the signals measured as shown above, and that the DC-DC converter works fine. Moreover, after re-soldering C10, the signals at the various test points as shown on the oscilloscope are quite the same as in the shots above, so there’s nothing wrong there. Plus, DCFF through C10 really helps Q7 working without getting hot, so it does a valuable job after all. Why hadn’t I measured -65V before then? I don’t really know. Maybe I just did a bad debugging job (perhaps I had not tested the voltage at the cathode of D1?). Maybe the chip did not sense -65V and was periodically restarting the converter? I have not the silghtest idea. Anyway, I won’t grieve about it, I ‘m happy that this all ended and I am up to my next steps.
Update, March 26 2009: the last few days I have been busy progressing with the initialization and calibration sequence of the 3210 as suggested in An35. During these tests, I hit another stupid bug of mine. I noticed that the manual calibration routine for the RING gain mismatch (cf. An35, p.3) was not completing successfully: I was writing 0x1F to DR 88 as suggested, and then stepwise decrementing that down to zero, however DR 88 kept displaying 0xFF — the largest possible value (for sure not close to the desired value of zero, right?). This led me into re-checking my schematic. Guess what: there is an off-by-10 error there: whereas R7 should have a value of 4.02kOhms, I have erroneously set a value of 40.2kOhms for it. So, I am going to replace R7 and re-try. I really do hope that I will not have any other major bugs. After this bug fix, I also owe a new version of the schematic and BOM with the correct value for R7, which I ‘ll post soon after making sure that changing R7 into the correct value fixes the problem. One more thing, too: meanwhile, among all my other debugging attempts, I fixed a bug in my PCLK TIMR1 ISR code (I was dropping PCLK 5 cycles too soon within the ISR code, and this is apparent in the PCLK oscilloscope shot above, which shows a duty cycle ~40%). So now I have a PCLK which is much better than the one in the shot above. Thus, I also owe to post the new, changed ISR code. Lots of TODO’s…
Update, March 26 2009 (later): replacing the correct value for R7 (~4.1k, made from two E12 8.1k resistors in parallel) fixed it! The Ring gain mismatch calibration works now OK! So, I am moving on…