As you may guess from the title of this post, things went as good and as bad as they could. But let′s take things in order.
The first thing after finishing the solderwork was to do a few measurements to make sure I had no shorts. Everything OK there, so I went on. An accidental drop of my board on th floor resulted in the +5V line of the USB receptacle getting disconnected (I have already said that my home-made PCB was not first quality), so I had to fix that. Done, then everything was looking OK, so I had to try the DC-DC converter.
To do that, I had to write Direct Registers and one Indirect Register of the 3210 (namely, from the DC-DC converter Excel, I had to set DR#92 to 202, DR#93 to 12, DR#74 to 44 and IR#40 to 0). Plus, by doing some reading, I found that I had to set DR#14 to 0 in order to bring the DC-DC converter up.
I could write the required code in two places, either in PIC firmware, or in software. A quick look at the Zaptel driver informed me that the authors there provided four functions (read DR, write DR, read IR, write IR) that interface with a 32xx chip and then all work is done via these four functions in the kernel driver space. This convinced me to confine my newly-acquired firmware expertise into writing the equivalent of these functions only, and do the rest of the work in my .NET controller program (remember that I am targetting this project for Linux, but in the meantime I am doing the development work in my home PC which runs Windows).
Actually, the “read DR” function I had already written, so I only had to write three more functions. I decided to deviate a bit from the zaptel code, and write down a debug version of the “write DR”, which would check back the value just written to a register, by re-reading the register and doing a compare. Then, I copy-pasted these two functions into respective ones for indirect registers. It seems that copy-pasting introduced just about every bug typical to a beginner in programming in only twenty or so lines of code… After two days of fruitless debugging, during which the 3210 was driven into a non-responsive state, I erased all the code of the indirect register functions and re-wrote that from scratch. This time everything worked fine.
I thought that now it was easy to change my .NET program to display all registers. Well, yes, it was easy, but it required extensive copy-pasting in order to draw the GUI, so I let go after drawing up to DR#20. Here is what my controller program’s GUI looked like at the time:
Then, I wrote a little sequence of register read/writes to bring up the DC-DC converter and then monitor its output via DR#82 (DR#82 monitors the DC-DC converter voltage, consult the 3210 datasheet for details). The picture above shows how close I (ever) got: the value of DR#82, appropriately translated into a voltage, is showing 63V, where the theoretical value should be 65V. Not bad at all! I shut down my computer and went to sleep late at night.
It turned out that this would be my project’s best result.
The next day, DR#82 started to show lower and lower measured output voltages, until a few days later it reached something as low as 2V and stayed there (of course I measured the same voltage using a meter; DR#82 was not lying, something was wrong indeed).
Soon this turned into my worse nightmare: my circuit was not working correctly, plus it was exhibiting variable behavior, and I could not tell why. It looked like an issue in the 5V power supply of the converter, but what exactly? After one week or so of nightly measurements I tracked down the issue to a finding that I did not like: my circuit had a low resistance from 5V to GND — only 200 Ohms. I did not know for sure, but this did not feel correct, since there was no path in my circuit that should have such a low resistance. I started unsoldering some components to isolate parts of the circuit. I even unsoldered the whole 3210 (which proved to be a fatal mistake), but the 200 Ohms resistance was still there.
I finally tracked down the issue into C31, which measured an ESR of 200 Ohms. Duh!… Either the capacitor was damaged (which I doubt, since I always measure components before soldering), or its low maximum voltage (6V) had let it burn. Who knows.
Thinking that I had solved my problems, I re-soldered a new 3210 in place (fortunately, I had — and I still have — a few of these in stock). However, this time I somehow managed to introduce a short between the pins VDDD and GNDD of the 3210 (pins 30 and 31, if I remember correctly). The cause of the short was invisible with my magnifying lenses. In spite of my many attempts to fix it, each time I cleaned the area and re-connected my circuit to the USB, the short was there again, causing a continuous spike which was overheating the area (it was even audible and produced a thin line of smoke) to the degree of melting the tin flux and re-reproducing itself. While trying to remove this short, I destroyed the pads around the 3210 on my one and only PCB.
At that time, I decided to declare the project R.I.P. After all, the project had been accumulating lots of bad Karma lately: my first blog had been erased without notice, my circuit had not worked as expected and the only PCB I had had been damaged Beyond Local Repair. This was enough for me to feel that this was The End for my project.
However, David, to whom I confessed my failure, offered to send me some hardware to help me go on, plus, even more important, he stressed to me that the hardware bugs are second order, because the essense of the work is the firmware and the drivers. I was convinced by the Voice of Reason speaking through these words, thus I accepted David’s generous offer and at the same time I ordered a quad of PCBs from trade, as I probably should have done from the very beginning. And, I am going to give it a second try. It’s worth it, don’t you think? And, if you have not been reading this blog from the very beginning, it’s also worth noting once more that this project owes its existence to David!