I'm trying to interface the TLV5606 with an mbed via SPI.

The connections I've made are as follows:

Note: mbed is powered from same 5V supply.

enter image description here

I modified the mbed SPI helloworld prorgam:

    #include "mbed.h"

SPI spi(p5, p6, p7); // mosi, miso, sclk
DigitalOut fs(p8);

int main() {
    fs = 0;

    uint16_t fixed = 0x4000;
    uint16_t value = 1024;

    value = value - 1 << 2;
    uint16_t final = fixed | value;


    fs = 1;

    fs = 0;


    fs = 1;


The first 4 bits (from the left) should be 0100, and the last 2 bit, 00. The 10-bit value goes in between. This is explained in the datasheet (http://www.tij.co.jp/jp/lit/ds/symlink/tlv5606.pdf).

I've used the bit pattern 0x4000, and XOR'd it with the 10-bit value, which is shifted by two. This should result in a bit pattern accepted by the DAC.

At first, OUT, as measured by the voltmeter is around 9mv (usually -9mv). After between 5 and 20 seconds (approx), the voltage spikes to around 1.6v, and once 3.3v. With a value of 1024, you would expect a value close to 3.3v (the reference). On occasion, the 1.6v spikes up to around 3.3v after a few minutes. Also, after having risen to 1.6v or 3.3v, the voltage will often drop back down to 9mv after some time.

I should mention that I haven't used a capacitor in this circuit, although I don't think it's necessary to test the basic functionality.

Any thoughts on what's going wrong?

  • \$\begingroup\$ Show how you made the connections in a schematic if you think that is important. \$\endgroup\$ – Andy aka Aug 3 '18 at 15:53
  • \$\begingroup\$ @Andyaka, schematic added. \$\endgroup\$ – 19172281 Aug 3 '18 at 16:25
  • \$\begingroup\$ Does anybody have a solution to this? \$\endgroup\$ – 19172281 Aug 3 '18 at 21:01
  • \$\begingroup\$ I've seen devices say they are SPI mode 0, which ends up being SPI mode 1 according to the MCU. Don't assume anything @B4039 and go through every detail again. Add bypass caps anyways (they can only help.) Make sure the timing requirements are being met. Try a slower clock rate at first. 'Scope the pins and see what they are really doing. \$\endgroup\$ – rdtsc Aug 4 '18 at 3:42
  • \$\begingroup\$ Which SPI mode does the DAC need? Hard to decipher the datasheet. \$\endgroup\$ – 19172281 Aug 4 '18 at 10:12

Three issues stand out in this:

  1. final = fixed ^ (value << 2) gives you 0x5000. As final[12] is a "don't care", then you are actually feeding zero scale to your DAC, which is what you're observing. The mistake here is that the scale runs from 0 to \$2^N-1\$, so you need to do value = 1023 << 2 then OR that together with fixed (rather than XOR; doesn't make a difference in this case but this is the safe way to combine two values). You should be sending 0x4FFC to go to full scale output.
  2. You say you "haven't used a capacitor". Well, you need to! At the bare minimum, you DAC should have a small (10-220 nF) bypass capacitor at \$V_\mathrm{DD}\$. Never exclude these in digital circuits, eliminate obvious problems first otherwise you won't be able to determine reliably what's causing failures.
  3. SPI is a pain (it's not a proper standard, just ad hoc), but I think you should be using mode 1, not mode 2. Compare Figure 1 in the datasheet, with this page from the mbed manual, and the following image (from Wikipedia). In mode 1, output is updated on the rising edge, and read on the next falling edge, which corresponds to the DAC's datasheet. As mentioned in the comments, do play with this, it's a very common problem in SPI setup. You will not be the first or last, I promise you!

enter image description here

  • \$\begingroup\$ Ok, I've made some minor modifications. I've added a 0.1uf bypass capacitor, and I've removed all "wait()" functions from the code. As a result, the DAC output now updates instantly, and remains constant. What I have noticed is that the output is always half of what it is supposed to be. For example, for 512, the output is 0.8v. For 1024, it is 1.6v. This to me suggests that SPI is working correctly (I have tried both mode 1 and 2, and there appears to be no difference. \$\endgroup\$ – 19172281 Aug 12 '18 at 21:20
  • \$\begingroup\$ 0x4FFC is what I initially thought was being output to the DAC. I tried replacing final with 0x4FFC, and oddly, the DAC output is 5v (despite a 3.3v ref). \$\endgroup\$ – 19172281 Aug 12 '18 at 21:21
  • \$\begingroup\$ Ok, I'm even more confused now. With 512, the result stayed at 0.8v for a few minutes, then spiked up to 3.3v, and back down to 0.8v. It was briefly 9mv. \$\endgroup\$ – 19172281 Aug 12 '18 at 21:30
  • \$\begingroup\$ I've updated the bit pattern calculation to: uint16_t fixed = 0x4000; uint16_t value = 1024; value = value - 1 << 2; uint16_t final = fixed | value; \$\endgroup\$ – 19172281 Aug 12 '18 at 22:40
  • \$\begingroup\$ Code listing in question has been updated. \$\endgroup\$ – 19172281 Aug 12 '18 at 22:42

Checking the TLV5616 datasheet (http://www.tij.co.jp/jp/lit/ds/symlink/tlv5616.pdf), this is the pinout I see:

enter image description here

According to your stated connections, you've connected pin 5 to 5V (it should be analog ground) and pin 8 to Ground (it should be VDD). Other connections are wrong as well.

Either your chip is completely miswired, or you got confused when listing your connections.

  • \$\begingroup\$ I made a mistake when listing the connections. I've edited the question. \$\endgroup\$ – 19172281 Aug 3 '18 at 15:59
  • \$\begingroup\$ I'd recommend you add a schematic. Much easier to follow than listed connections. \$\endgroup\$ – Selvek Aug 3 '18 at 16:01
  • \$\begingroup\$ Schematic added \$\endgroup\$ – 19172281 Aug 3 '18 at 16:12
  • \$\begingroup\$ Is it possible that the 16-bits are being sent in reverse? \$\endgroup\$ – 19172281 Aug 3 '18 at 17:04
  • \$\begingroup\$ Could this have something to do with the SPI mode? \$\endgroup\$ – 19172281 Aug 3 '18 at 21:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.