I caught on to a promotion from AVNet last week, in which one may get a freeMAX5214 eval board (available through August 31), so hopped on it because really, why wouldn’t I turn down free hardware? I promptly forgot about it until today, when a box arrived from AVNet.
What’s on the board
The board features four Maxim ICs:
MAX8510– small low-power LDO. Not terribly interesting.
MAXQ622– 16-bit microcontroller with USB. I didn’t even know Maxim make microcontrollers!
MAX5214– 14-bit SPI DAC. The most interesting part.
MAX6133– precision 3V LDO (provides supply for the DAC)
The MAXQ622 micro (U2) is connected to a USB mini-B port for data, and USB also supplies power for the 5V rail. The MAX8510 (U4) supplies power for the microcontroller and also the MAX6133 (U3). The microcontroller acts as a USB bridge to the MAX5214 DAC (U1), which it communicates with over SPI. The SPI signals are also broken out to a 4-pin header (J4).
The software included with the board is fairly straightforward, providing a small variety of waveforms that can be generated. It’s best demonstrated photographically, as below. Those familiar with National Instruments’ LabView environment will probably recognize that this interface is actually just a LabView VI (Virtual Instrument).
Rather more interesting than the stock software is the possibility of reprogramming the microcontroller. Looking at the board photos, we can see that there’s a header that breaks out the JTAG signals. With the right tools, it shouldn’t be very difficult to write a custom firmware to open up a communication protocol to the device (perhaps change its device class to a USB CDC for easier interfacing). Reprogramming the device requires some sort of JTAG adapter, but I can probably make a Bus Pirate do the job.
With some custom software, this could become a handy little function generator- its precision is good and it has a handy USB connection. On the downside, the slew rate on the DAC is not anything special (0.5V/µs, -3dB bandwidth is 100 kHz), and its output current rating is pretty pathetic (5 mA typical). With a unity-gain amplifier on the output though, it could easily drive decent loads and act as a handy low-cost waveform generator. Let’s get hacking?
I recently pulled a few SDR (133 MHz) SO-DIMMs out of an old computer. They sat on my desk for a few days until I came up with a silly idea for something to do with them: rewrite the SPD information to make them only semi-functional- with incorrect timing information, the memory might work intermittently or not at all.
Most reasonably modern memory modules have a small amount of onboard persistent memory to allow the host (eg your PC) to automatically configure it. This information is the Serial Presence Detect, or SPD, and it includes information on the type of memory, the timings it requires for correct operation, and some information about the manufacturer. (I’ve got a copy of the exact specification mirrored here: SPDSDRAM1.2a.) If I could rewrite the SPD on one of these DIMMs, I could find values that make it work intermittently or not at all, or even report a different size (by modifying the row and column address width parameters).
The SPD memory communicates with the host via SMBus, which is compatible with I2C for my purposes.
SDA (I2C data)
SCL (I2C clock)
VCC (+5 Volts)
The hardest part of this quest was simply connecting wires to the DIMM in order to communicate with the SPD ROM. I gutted a PATA ribbon cable for its narrow-gauge wire and carefully soldered them onto the pads on the DIMM. Per information at pinouts.ru, I knew I needed four connections, given in the table to the left.
Note that the pads are labeled on this DIMM, with pad 1 on the left side, and 143 on the right (the label for 143 is visible in the above photo), so the visible side of the board in this photo contains all the odd-numbered pads. The opposite side of the board has the even-numbered ones, 2-144. With the tight-pitch soldering done, I put a few globs of hot glue on to keep the wires from coming off again.
With good electrical connections to the I2C lines on the DIMM, it became a simple matter of powering it up and trying to communicate. I connected everything to my Bus Pirate and scanned for devices:
The bus scan returns two devices, with addresses 0x30 (write-only) and 0x50 (read-write). The presence of a device with address 0x50 is expected, as SPD memories (per the specification) are always assigned addresses in the range 0x50-0x57. The low three bits of the address are set by the AS0, AS1 and AS2 connections on the DIMM, with the intention that the host assign different values to these lines for each DIMM slot it has. Since I left those unconnected, it is reasonable that they are all low, yielding an address of 0x50.
A device with address 0x30 is interesting, and indicates that this memory may be writable. As a first test, however, I read some data out to verify everything was working:
I write 0 to address 0xA0 to set the memory’s address pointer, and read out the first three bytes. The values (0x80 0x08 0x04) agree with what I expect, indicating the memory has 128 bytes written, is 256 bytes in total, and is type 4 (SDRAM).
Unfortunately, I could only read data out, not write anything, so the ultimate goal of this experiment was not reached. Attempts to write anywhere in the SPD regions were NACKed (the device returned failure):
In the above block, I attempted to write zero to the first byte in memory, which was NACKed. Since that failed, I tried the same commands on address 0x30, with the same effect.
With that, I admitted failure on the original goal of rewriting the SPD. A possible further attempt to at least program unusual values to a DIMM could involve replacing the EEPROM with a new one which I know is programmable. Suitable devices are plentiful- one possible part is Atmel’s AT24C02C, which is available in several packages (PDIP being most useful for silly hacks like this project, simply because it’s easy to work with), and costs only 30 cents per unit in small quantities.