After having soldered all three ICs on my PCB, I had to choose between two paths: either to solder all components, or to solder just one part of the circuit at the time, debugging incrementally as I would go on. I decided to go incrementally, starting from the PIC circuitry, then going into the interface between the PIC and the 3210, then into the DC-DC converter and the interface between the 3210 and the 3201.
So I soldered all the components around the PIC, removed a few short-circuits here and there (my PCB’s top and bottom sides weren’t very well aligned, something that caused some more of these) and used the ICSP with a modified version of FDART2003 (see picture below) to program the PIC with a version of the bootloader modified so that it would use my choice of PIC ports for the user switch and the user LED. Plugged the USB connector in and — nothing…
A modified version of FDArt2003 for my board
But OK, I had seen this play before, so this time I did not panic. I double-checked the PIC ports in the bootloader source, fixed a bug there (some mask was not right), then re-tried. Still nothing… I re-checked my PCB for power — and there was it: the 5V pin of the USB connector was not soldered well and, altough it passed my first tests, it had been disconnected, and the PIC was not getting any power. Fixed this, and the green LED came into life with a reassuring flash.
Then, using the USB and the bootloader, I flashed the firmware for Microchip’s demo board, after removing lots of unneeded things and adapting the signals to those of my board. LED flashing again (this “user” firmware program instructs the LED to flash at a slower rate and one can see easily whether the bootloader or the user firmware is running). So the PIC-related part was looking OK now.
But so far it had been the easy part… Now it was time to move to the unknown territories of the 3210. I soldered just the decoupling capacitors and the little ferrite bead (the BLM something on the schematic), so as to give power to the chip, leaving all other external circuitry out. Adhering to my incremental testing plan, at this point I just wanted to test the SPI communication between the PIC and the 3210. A successful test result would also serve as a proof that I had not damaged the 3210 during soldering.
To test the SPI, I modified a little program written in .NET that Microchip provides, adding my own USB command between the PC and the PIC (the firmware uses one-byte commands for that) and displaying the result (and verified that part OK by passing successfully fake results from the firmware to the PC). The idea was that the program would query every second or so my board about the “current” 3210 register value, and my board would return the value of the same “current” register all the time, until the “user” switch was pressed, in which case the board would step on to the next register, and so on. After I verified that stepping the registers with the “user” switch was working OK, I went on into testing the SPI itself.
So, I studied a bit the SPI interface of both chips. This can be found in p.53 of the 3210 datasheet and on p.200 of the PIC 18F2550 datasheet. Mumble, mumble, the SPI interface has four “modes” depending on whether the clock signal is high or low during inactivity and on whether the data bit is asserted on the rising or on the falling clock edge in the middle of a clock cycle. And this, by a de facto standard from other vendors, is coded into four names, like “mode00″, “mode01″, “mode10″, and “mode11″. Good, nothing too difficult so far.
To complicate things, Microchip use the opposite logic level for one of the two bits controlling this setting (I think it is the CKP bit), so that e.g. “mode11″ corresponds to CKP=0. Duh!… Anyway, by placing both diagrams next to one another, I could tell that I needed CKE=1 (clock is high during inactivity) and CKP=0 (data asserted on rising edge), which oddly translates into “mode11″. Microchip have a library for SPI operations, so it sounded like my job would be as easy as this: OpenSPI (parameters), WriteSPI (command-to-read-a-register), then value=ReadSPI ( ).
Good, I flashed that into the PIC and – you guessed it right: It didn’t work… Not with any clock frequency I tried. Not with any SPI mode I tested. Not when I let go of the SPI routines and re-did the whole procedure manually, testing bits and writing bytes to the appropriate control registers of the PIC. Not with that, nor with any other trick I could imagine. The damn thing was always returning zeros or –
There was a reassuring sign though! Using some settings, I was receiving some bits set to one. This meant that there was some sort of activity between the 3210 and the PIC. The 3210 was sending logic ones sometimes, so it could not be entirely dead. It had to be something else I was not doing right. But what? As much as I scratched my head on this, the results I was getting did not make any sense to me.
It was again the time to express my despair to David Rowe and turn to him for help. David’s reply was very, very helpful. The 3210 does not reset properly unless the PCM clock is applied to the chip before resetting it. And, if the chip does not reset properly, the SPI bus does not work correctly. Actually, all this I had already read in an FAQ from Silabs (bottom of p.5), to which of course I had not payed any attention. David’s advice un-stuck me from a point at which I would have dropped the project altogether — this is just another reason why, as I said also before, this project owes a lot to him! Thanks, David!
So, I had to postpone my attempt to talk to the 3210 over SPI, and I had to go into one of the design quizzes that had been puzzling me for quite some time in parallel: how to generate the 256 kHz signal needed for the PCM clock and at the same time do PCM I/O between the 3210 and the PIC. But this is described in my next post.