Post

As per lab specifications, the DAC hardware was installed and tested on the micro board (including all necessary filtering etc.).
All initial tests indicated that the DAC was properly installed and working within specified limits.
The subsequent part of the lab was to write code to create a sinewave out from the DAC, then to optimise the code to exceed the specified minimum frequency. Upon demonstration of the code running in ram, small modifications were to be made to allow the program to run from startup and the program was then to be bootloaded into the EEPROM and the entire system demonstrated to obtain checkoff.

The code worked fine in ram, producing a very nice sine wave out of the DAC. However, the modified code loaded into EEPROM for execution from startup failed to produce anything even remotely resembling a sinewave.
Initial suspicion was that the modifications made to the code prevented it from running, or that the minimal OS was taking care of some other aspect of the microcontroller that the DAC lab code was failing to initialize.
Code was examined line by line, each instruction checked and logic evaluated. The actual assembly produced by the assembler was also checked to ensure the proper form of instruction was being chosen.
After this failed to turn up any errors, the focus was shifted to the hardware.

Visual inspection revealed no obvious problems (any obvious flaws were caught and corrected before reaching this state). An oscilloscope was used to probe various pins relevant to the DAC subsystem. The output waveform (unfiltered) stayed low, though occasionally showed a minor pulse at regular intervals, indicating that the DAC was attempting to do something but was dying part way through the first cycle. The first significant issue detected was on SCLK (SPI clock). SCLK would show the proper clock pulses required to drive the DAC, but sometimes instead of a clear pulse, the voltage exhibited an exponential decay, even though there should have been no capacitance at that point. This explained why there was no wave out, but the cause of the SCLK glitch was still unknown at this point.
The second major breakthrough was that when SS (slave select) was probed, the clock was magically fixed until a reset pulse (at which point, the exponential decay was again seen). This raised some interesting questions since there was absolutely no logical reason why probing SS would fix SCLK. And didn't explain why SCLK was broken in the first place. Since this behavior was extremely abnormal, the chip was pulled on the suspicion that it may be blown. Logic levels were then tested on the socket while the chip was out. This revealed that there was no +5V into the chip on pin 1. The +5V rail was tested as well as the pin where the connection was made from the rail to the socket. The rail and pin tested fine, but the socket was showing no voltage to the chip. The wirewrap connection was inspected and although it appeared sound, solder was applied to ensure a solid connection. The socket now had +5V on pin 1 and the chip was re-inserted. The system was booted and the desired sinusoidal waveform appeared on the scope's display.

In summary, either the connection was good enough that when the chip was inserted, some current was able to flow through it, or the DAC8512 itself was putting approximately 2.2V out on pin 1 (Vin). When operating from ram, this problem did not manifest, but became apparent upon operation from EEPROM and this is why hardware was not initially suspected (due to the (apparent) proper operation of the DAC).

All wirewrap connections on the board are now suspect, however the board now works and since tearing it down could (although unlikely) cause damage, it is not recommended that the board be rebuilt at this point, although if furthur problems are discovered, this would likely be the best course of action.