Progress during the last two months has been terribly slow, because of too much stress in my so-to-speak daytime job — a demanding project there turned it into a day-and-night occupation for quite a few weeks. But I haven’t dropped my openusbfxs project (or at least, not yet ). Thus, there are two things that I have managed to progress since my last post.
The first thing is that I have looked thoroughly through the direct register (DR) values that my 3210 returns to the controller program (shown in my last post, and repeated above as a thumbnail). Don’t quote me on this, however I was unable to find anything wrong with these values. If I am interpreting the 3210′s words correctly, it seems that the chip thinks that everything is fine, but still does not drive the DC-DC converter. Why is that so?
So I looked a bit more into what is happening in my second prototype board, this time using an oscilloscope. I was happily surprised to find that the 256 kHz PCLK and the FSYNC signals initially looked OK (at least, at first glance — this was actually the first time I have been checking my board with a scope). What turned to be in a worse shape than expected was the PIC itself.
In my previous post I mentioned something about a benign ghost playing tricks on my board. An indication of that was a mysterious flickering on the status LED. The oscilloscope revealed the ugly truth: after a few minutes of operation, when the PIC warms up a bit (nope, it doesn’t get hot, it just warms normally), it seems to destabilize and produce a noisy signal instead of a steady logic-one. Thus, what previously used to be a on-off signal (the signal driving the status LED), after a while becomes a sequence of noise-then-silence cycles. As the circuit remains under operation, the problem keeps worsening, resulting into a highly noisy pattern instead of a logic-one.
Why did not this show up in normal operation but only in bootloader mode? The answer is it did show up in both cases. However, normal operation has a much longer LED flashing period than bootloader mode. So, in normal operation the LED was flickering during a longer time and the human eye was tricked into seeing it as if it were constantly lit; whereas, the much shorter flashing period in bootloader mode (about 5Hz) did not provide enough time for the LED to become “incandescent” (light up in full-power) so the flickering was more apparent to the eye. A more careful inspection after scoping the board revealed that the flickering was also visible under normal operation.
What’s even worse is that this noisy logic-one signal does not contain itself into the LED-driving signal; it also appears in the PCLK line. Thus, from an initial 256-kHz series of logic-ones and logic-zeros, the PCLK signal slowly turns into a 256-kHz succession of noise-then-logic-zeros. My guess is that this explains perfectly well why sometimes the 3210 fails to operate its SPI interface correctly and returns unexpected values or values consisting of all-ones.
Since this error does not occur until the PIC is a bit lukewarm (plus I could not see anything suspicious on the crystal oscillator pins), my guess is that something is likely wrong with the PIC itself. Thus, I have ordered a couple of new PICs in order to replace the one on-board. However, and to be on the safe side, I ‘ll first try replacing the oscillator crystal — anyway, quite easier and faster than replacing the PIC, so why not try it after all.
In any case, I think that an educated guess is that the noisy PCLK signal is what inhibits the 3210 from operating correctly its DC-DC converter driver. But time (plus replacing suspected components) will show.
I hope that this time I ‘ll be back posting much sooner, and that I ‘ll be bringing good news. Till then, do wish me a successful debugging session. Have I told you how much I hate bugs? Yes? Well, I wish they hated me as much as I hate them! Alas, this is not the case…
Update Feb 24 2009: after replacing the crystal, and as far as I can tell from visual inspection of the LED, the noise in the logic-one signal seems to have vanished; so, it seems that the culprit was the crystal and it was not the poor PIC’s fault after all. Nevertheless, fixing the logic-one signal did not fix the issue of the DC-DC converter not functioning. I am going to re-inspect the board with an oscilloscope to help me in locating the next bug in the queue. It may be that the 3210 was damaged during soldering and needs to be replaced (right now, this seems to me the most plausible explanation).
2nd update Feb 24 2009: after examining the board with a scope, it seems that this time there is a clock drift in the PCLK line. Although the last time I had observed noise, the clock was perfect and there was no drift at all. Seeing a clock drift now leads me into suspecting again the PIC (probably its PLL?), so I ‘m going to replace it in any case.
Update Feb 25 2009: I have replaced the PIC, however register 82 still remains stuck to zero. I ‘ll re-scope the board to check how the clock signals around the PIC are looking and will update the post later on.
2nd update Feb25 2009: ok, the clock now looks fine, however the 3210 still declares itself “unwilling to perform” (if the phrase rings a bell to you, it’s an LDAP protocol error message) . My next suspect then is the 3210 itself. Although it should, it does not produce any frequency to drive the DC-DC converter circuitry. So, I ‘ll try replacing that and see what happens.
Update Feb 26: nope, it was not the 3210. The replacement 3210 behaves exactly the same as the previous one [remember that I am not an electronics expert at all, so this simple "changineering" strategy (replace suspected components until the problem is confined so that it becomes apparent) is all I can do for now]. I have observed a change in the voltage of SDCH (pin 8 of the 3210) when DR 14 is set to zero. So my next step will be to note down carefully voltages around the DC-DC converter circuitry in both states (DR 14 = 0×10 and 0×00) and see where this leads me.
2nd update, Feb 26 (and last for this post): partial success! I managed to see 65V again (then lost it). By observing voltages, I noted an incosistent value in SDCL (5V on the 3210 pin and 4.2V elsewhere in the circuit), which led me into fixing a bad via underneath the 3210. The 3210 now drives correctly Q8, however Q8 does not seem to let through R16 enough current to drive Q7 into its conducting state. So, next thing to try is replacing Q8. Remember that this intermittent operation was the exact same behavior that my first prototype had; so I am now suspecting a bad choice of some specific component (and Q8 is a good candidate).