This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DAC8218 analogue output

Other Parts Discussed in Thread: DAC8218, DAC7718, DAC8718, REF5040, DXP, DAC8218EVM, REF5030

Hi,

we have a big problem using a DAC8218. Our communication with the device works well. Which we can see at the GPIO handling. We can write and read the registers. But we never get the analogue output which we expect after calculation the formulas.

Are there any erratas for the DAC8218? The youngest data sheet is from December 2009.

Does anyone have experience with the DAC8218 and can give us some advice?

Thanks!

Regards Jan

  • Hello Jan,

    Apologies for the delayed response. It seems somehow the system did not alert me of your post.

    Harald Hellmann13 said:
    Are there any erratas for the DAC8218? The youngest data sheet is from December 2009.

    This is not a know issue for the DAC8218 so there is no errata for this behavior.

    Harald Hellmann13 said:
    But we never get the analogue output which we expect after calculation the formulas.

    What is the deviation from your formulas to your measured output? If you could share with me your calculated and measured results I can verify them for you.

    What is the load at the DAC output?

    Note a few common customer problems with this device:

    • Make sure that you connect the thermal pad to AVSS
    • Make sure that you follow the proper power supply sequence outlined in page 44 of the DAC8218 datasheet

    Failing to implement these can cause miscellaneous problems both in the digital and analog domain.

  • Hello Eugenio,


    sorry for the very very late response and thanks for your reply.

    Eugenio Mejia said:
    Make sure that you connect the thermal pad to AVSS

    We have the 64pin TQFP package so there is no thermal pad.

    Eugenio Mejia said:
    Make sure that you follow the proper power supply sequence outlined in page 44 of the DAC8218 datasheet

    We`ve followed these power supply sequence and duoble checked it, all works correct.

    Eugenio Mejia said:
    What is the deviation from your formulas to your measured output? If you could share with me your calculated and measured results I can verify them for you.

    We`ve made a picture of our calculated and measured results:

    1. Calculated result:

    2. Measured result:

    Please note that the result isn`t somehow linear.

    Here`s the code that produces these results:

              printf("DAC auto measurement offset/value\r\n");
              printf("Offset;Dac;U/V\r\n");
              for (cnt = 0; cnt < 16; cnt++) {
                SPIwrite(3, cnt << 12); //Offset
                for (num = 0; num < 16; num++) {
                  stc = Systick;
                  SPIwrite(8, num << 12); //Dac0
                  swd = measure();
                  printf("%d;%d;%i,%02d\r\n", cnt, num, swd / 100, abs(swd) % 100);
                  while (Systick < stc+3) { }
                } //for num
              } //for cnt

    The outer loop is running 16 values from 0x0000-0xF000 and sets the offset register. The inner loop is also running these values and sets the DAC-0 register.

    I hope this is enough information for you to verify the problem. If you need anything else or special, please tell me and we will provide.

    We`ve found two erratas in the datasheet:

    1. In figure 98, page 40 a dot is missing (red mark):

    2. There is a mismatch between the "absolute maximum ratings" (page 2) and the description in "power-on reset sequencing" (page 44):

    IOVdd should not be greater than DVdd+0.3.

    On page 44 the datasheet says: "IOVdd and the digital pins must be applied before or at the same time as DVdd."

    But when IOVdd is applied before DVdd the result is that IOVdd is greater than DVdd.

    Thanks!

    Regards Jan

  • Hi Jan,

    Harald Hellmann13 said:
    1. In figure 98, page 40 a dot is missing (red mark):

    Harald Hellmann13 said:
    2. There is a mismatch between the "absolute maximum ratings" (page 2) and the description in "power-on reset sequencing" (page 44):

    I will make sure we add these to the change list for the new revision. Thank you for pointing this out.

    I have a few questions/suggestions in order to help me debug this problem:

    • What supplies are you using?
    • What is the SCLK frequency?

    Harald Hellmann13 said:
    SPIwrite(8, num << 12); //Dac0

    • I am not sure how your SPI write function works. I assume that the first argument takes care of the address that you want to write to. The second argument should be the data. You are shifting by 12 instead of 10? Do you mind explaining why?
      • If I understand correctly, the largest value you are shifting is 15, which is a 4-bit number, if you shift by 12, you will make it a 16-bit number, but the data register can only fit a 14-bit number, causing an overflow.
    • Can you share the printout of the SPI codes that SPIwrite() is sending to the DAC it would be useful. i.e. the output of a printf() inside SPIwrite().
      • I want to make sure that the codes that you are writing to the DAC are what we expect.
    • I would also suggest increasing the number of system ticks to allow the DAC output to settle more clearly in the graph.
      • Just for debugging purposes, so I can count where the problem starts to occur.

  • Hi Eugenio,

    thank you for your response. I will answer your questions.

    Our power supplies are: IOVdd = 3.3V and connected to DVdd also. AVdd = +12V, AVss = -12V, REF-A and REF-B = 4096mV.

    Our SCLK frequency is 4MHz.

    Your assumption is right. The first parameter is the register address and the second parameter the value for it. Yes we are shifting 12 bits because the shift register is explained in Table 9 Shift Register Format on page 47. The 14 bits used are left justified within the registers. Therefore no overflow will occur.

    We can send you a debug output not before tomorrow afternoon. But I can make sure that the communication works well because writeing and reading back registers give the right values. Furthermore working with the GPIO register can be checked outside of the chip and give the right value on input.

    I will zoom into the scope picture of the DAC output. because it is just made small to show all of the 256 values. The settling time works well.

    With Kind Regards

    Harald Hellmann

  • Hi Eugenio,

    I want to continue with my information. Details source code running the SPI will be much overload the theme. Just to mke you sure what we are doing have a look on the following picture. It is a set GPIO command by SPIwrite(2, 0x4000); long before (left of) the picture followed by a DAC soft reset by SPIwrite(0, 0x2000);.

    Each signal is well identified. You can see the three bytes of the DAC soft reset command @ the MoSi signal and also the set GPIO command from before as the answer comming in by MiSo. The signals are triggered by assertion of /CS. By negation of /CS after 14.8µs the soft reset command will happen and turn off the GPIO-0 and setting the DAC-0 output as well. With a more detailed picture by a zoom into the second transfered byte you can see the polarity and phase and even timing of the SPI looks well.

    In addition to our picture of the 16 times offset and 16 times dac values from yesterday I have added two GPIO signals showing the lower two bits of the offset value.

    You see even if we change the programm a little bit by adding SPIwrite(2, (cnt & 0x03) << 12); before setting the offset @ line 4, the dac output will be the same as yesterday. As you requested we zoom at the beginning and in the middle.

    Each tick on the /CS signal (3ms of distance) is setting the next value of the dac register. At points in time where the GPIOs change the offset registe is set as well. The correction engine is not activated. Our data format is set by connection of Btc/Usb to high to bipolar twos complement . RstSel is also connected to IOVdd (high). /LDAC is kept low for imediately response. You can see for the first eight dac values running from 0x0000 to 0x7000 an increase of the output but it is not linear. The values of 0x8000 up to 0xA000 is clipping at the negative maximum. The values from 0xB000 to 0xF000 are even more non linear. The zoom in the middle of the numbers is spread once more in the timebase.

    The center of the screen shot it the point where offset is turning from 0x7000 to 0x8000 and dac is turning from 0xF000 to 0x0000.

    What else do you have to know to help us getting the right values out of the dac? For this pictures the load of the dac output was just the scope input.

  • Thank you for all the information you provided. It is very helpful to see all these cases.

    What is the USB/BTC voltage?

    Harald Hellmann said:
    The values of 0x8000 up to 0xA000 is clipping at the negative maximum.

    You are using ±12 V supplies, which is why the clipping happens close to -12 V and +12 V.

    What concerns me the most, is the non-linear effects in the middle of the ramps.

    Can you run each loop independently of each other and provide the plots? I want to see if we can isolate the issue to the main DAC output, or the offset DAC.

  • Hi Eugenio,

    thanks for keeping it running. As I stated out already we use Btc/Usb with a 10k to IOVdd. The high represents the bipolar twos complement format.

    To get the pictures a little bit more helpful I changed them a little bit. I'm running 32 levels instead of 16. The values are now 0x0000, 0x0800, 0x1000, 0x1800, 0x2000, ...... 0xE800, 0XF00 and finally 0xF800. Each step takes now 5ms. Therefore 4 steps are shown each 20ms of division. Also the Y-axis could be changed to 3V per division for a much better resolution. The screen shows now ±12V × 160ms of relevant signal plus 20ms before trigger plus 20ms after the steps. The first picture shows all signals to get you the points in time also.

    What I forgot is that I have set the gain to 4 to find the range of getting ±8.2V out of the DAC. Please keep in mind that we run 5ms per step. Therefore each division of 20ms we increase by 0x2000. In the middle of the screen the step from 0x7800 to 0x8000 appears which means from almost highest positive value to the most negative value in sense of bipolar twos complement. And finally for more resolution I take the analogue signal only. This looks for the offset of 0x0000 like:

    Setting offset to 0x1000 and running the DAC from 0x0000 up to 0xF800 looks like:

    With offset of 0x2000 it looks like:

    Now offset = 0x3000:

    And offset = 0x4000:

    The picture below has an offset of 0x5000:

    And now offset = 0x6000:

    And the final one before the sign changes. Offset = 0x7000:

    Now the first one the the other sign at offset of 0x8000:

    Please keep patient there will some more. Offset = 0x9000:

    And so on with offset = 0xA000:

    Now offset = 0xB000:

    And offset = 0xC000:

    Offset = 0xD000:

    Almost done at offset = 0xE000:

    And done at offset = 0xF000:

    Please pay attention to the offset of 0xC000 which looks much more noise than the others. Even running it a second and a third time didn't get it better.

    But I'm not ready yet because I want to get it running. I want to show you the behavior of the offset at fixed DAC values too. Therefore I took some more pictures. Let's start with DAC = 0x0000. The out looks like:

    when the offset is running from 0x0000 to 0xF800 in steps of 0x0800 each 5ms. With a DAC value of 0x1000 it looks like:

    DAC value of 0x2000 looks like:

    DAC value = 0x3000:

    DAC value of 0x4000:

    DAC value of 0x5000:

    And now DAC value of 0x6000:

    And the last one before the sign changes. DAC value = 0x7000:

    And the other sign starting at DAC value of 0x8000:

    Going further to DAC value = 0x9000:

    And DAC value of 0xA000:

    One more picture with DAC value = 0xB000:

    DAC value = 0xC000:

    And almost almost done at DAC value of 0xD000:

    And almost done at 0xE000 of DAC value:

    And done with the last DAC value of 0xF000:

    Even this way hay a lot of noise at DAC value of 0xD000 which appeared each time.

    Maybe a special signal is of interest. I kept the Pin-10, the OFFSET-A signal with the scope:

    Or just the analogue signal but pay attention to the expanded Y-axis of 800mV per division.

    Now I'm very interested in your answer. Please let me know if you need some more measurements. Thank you in advance for your support.

    With Kind Regards

    Harald Hellmann

  • Hi Eugenio,

    please do you have any idea because we have presentation in two weeks, where our analogue outputs should be shown. Shall we check if DAC7718 or DAC8718 is running. Nobody would check 12 bits only on a presentation. If they would work better we should get some samples.

    Please ask Robert Schreiber or Amit Gupta what we have done for TI. Now we need some help from TI.

    With Kind Regards

    Harald Hellmann

  • Howdy Harald,

    Eugenio is currently in training but I may be able to assist you with this post. We understand the importance of a solution within your schedule, and will try our best to help you debug and solve the issue you are experiencing. I'll need some time to look over this post, and forward any relevant information to colleagues. I'll update this post as I gather information and feedback.

    Best Regards,
    Matt
  • Harald,

    If possible, can you post a copy of your schematic? Or you can optionally send a copy of your schematic to the email address I provided in an e2e message.

    Best Regards,
    Matt
  • Hi Harald,

    The code you posted may be incorrect. I did a quick print out and got the following results for the DAC writes:

    0
    4096
    8192
    12288
    16384
    20480
    24576
    28672
    32768
    36864
    40960
    45056
    49152
    53248
    57344
    61440


    I believe you mentioned that the BTC line is connected to IOVDD, which means the input should be in twos complement format. The code above is an unsigned (16-bit) increment. The code includes the 2 extra don't care bits.

    For BTC:

    32768 to 65536 translates to (-FS to 0)

    0 to 32768 translates to (0 to FS)

    Therefore you may need to update your algorithm for BTC.

    Best Regards,
    Matt

  • Hello Matthew,

    as you requested by e-Mail a well running btc value I will provide the results for loops running from -32768 to 30720 in steps of 2048 and add a 33rd value with +32767.

    I know how counters with or without sign are running. Especially twos complement is just inverting the highest bit.

    Cnt, Unip., Hex,    Bipol., 2s com, Twos compl.
      0,     0, 0x0000,      0, 0x8000, -32768
      1,  2048, 0x0800,   2048, 0x8800, -30720
      2,  4096, 0x1000,   4096, 0x9000, -28672
      3,  6144, 0x1800,   6144, 0x9800, -26624
      4,  8192, 0x2000,   8192, 0xA000, -24576
      5, 10240, 0x2800,  10240, 0xA800, -22528
      6, 12288, 0x3000,  12288, 0xB000, -20480
      7, 14336, 0x3800,  14336, 0xB800, -18432
      8, 16384, 0x4000,  16384, 0xC000, -16384
      9, 18432, 0x4800,  18432, 0xC800, -14336
     10, 20480, 0x5000,  20480, 0xD000, -12288
     11, 22528, 0x5800,  22528, 0xD800, -10240
     12, 24576, 0x6000,  24576, 0xE000,  -8192
     13, 26624, 0x6800,  26624, 0xE800,  -6144
     14, 28672, 0x7000,  28672, 0xF000,  -4096
     15, 30720, 0x7800,  30720, 0xF800,  -2048
     16, 32768, 0x8000, -32768, 0x0000,      0
     17, 34816, 0x8800, -30720, 0x0800,   2048
     18, 36864, 0x9000, -28672, 0x1000,   4096
     19, 38912, 0x9800, -26624, 0x1800,   6144
     20, 40960, 0xA000, -24576, 0x2000,   8192
     21, 43008, 0xA800, -22528, 0x2800,  10240
     22, 45056, 0xB000, -20480, 0x3000,  12288
     23, 47104, 0xB800, -18432, 0x3800,  14336
     24, 49152, 0xC000, -16384, 0x4000,  16384
     25, 51200, 0xC800, -14336, 0x4800,  18432
     26, 53248, 0xD000, -12288, 0x5000,  20480
     27, 55296, 0xD800, -10240, 0x5800,  22528
     28, 57344, 0xE000,  -8192, 0x6000,  24576
     29, 59392, 0xE800,  -6144, 0x6800,  26624
     30, 61440, 0xF000,  -4096, 0x7000,  28672
     31, 63488, 0xF800,  -2048, 0x7800,  30720
     32, 65535, 0xFFFF,     -1, 0x7FFF,  32767

    My last week oscilloscope pictures are running the 'Bipolar' column but without the last (32) line. As you can see at the pictures the center of the data is placed to the center of the screen. Therefore you just have to exchange the left and the right half of the picture to get it the right way. My pictures today are running inclusive line 32 and are using the right most column of the twos complement value. Therefore values are running from -full scale up to +full scale.

    To make sure no external component will influence my signal I measure the OFFSET-A Pin 10 first. The 1st picture includes the digital signals and you can see the 33th action of count (cnt) = 32.

    Just to compare it with last week and the bipolar column you can see the left and right halfs of the screen exchanged.

    I just want to show the analogue output of the OFFSET-A Pin 10 only. Last week:

    And today with the twos complement values running loop (picture 1 offset):

    Where perfectly can be seen that we reproduce our result even with the twos complement data and the additional value of +full scale. The output voltage of +full scale is 3.927V getting it from a reference of 4096mV (REF5040). Please keep an eye on the y-axis division because I scaled it to get the most out of the range. Just a sentence more to explain what will be seen. Last week at the position off the trigger caused by the first /CS at a position of one devision from the left (20ms) we have the OFFSET-A value of 0 shows 3.927V which today appears right in the middle of the screen (5th devision or 100ms from the left).

    In addition I read the register contence bach from the chip and the GPIO and OFFSET-A registers changed only.

    I don't want to run all of the pictures from last week. But you should get some example running the dac with the twos complement value at some certain offsets. Therefore the dac value is running the twos complement values from -32768 up to +32767 in steps or 2048. Let's start with an offset-A value of -full scale (0x8000 = -32768) and at a gain of 4. I set the gain before the offset-A.

    You can see the dac output is overloaded from 0xD000 = -12288 up to 0x7FFF = +32767.

    Now the offset-A will be 0x9000 = -28672 and the dac output will shift down to some more negative values.

    The principle of the dac seems to work. The offset of 0x9000 looks at the picture 1 offset like about 500mV (two thirds of almost 800mV). At the gain of 4 the offset has a gain of -3 and we can see the dac output of about -1.5V (-3 × 500mV).

    The next checked offset-A value is at the end of the linear steps at 0xC000 = -16384 where the offset-A voltage looks like 1830mV.

    With the offset-A gain of -3 we get a dac value of -5.5V. So far so good. But now we see the dac output with the same non linear values like the offset dac does in picture 1 offset.

    Let's now check the first non linear step of the offset at 0xC800 = -14336 = about 2400mV at 45ms after trigger with the little noise on it.

    Wow, we see the starting value of the dac at the expected -7.2V and we have at all dac output level the noise from the offset dac. Compare it with the picture before. It's still the same non linear behaviour and looks very similar to the offset dac.

    The last check for today will be the most positive offset-A value of 0x7FFF = +32767 with the measured offset-A voltage of 3.927V

    The first dac output value is very close to -12V. Therefore offset handling looks well.

    But both dacs offset and output work very similar but strong non linear. What's going on here? Any ideas are welcome. Even some more measurements. But I'm sure we have all aspects measured to figure out where it doesn't work.

    TI requests from today:

    Can you temporarily remove the ’for’ loop for the offset and recapture waveform with oscilloscope.  Basically try to recapture the waveform with the non-linearity and provide the register dump out of the dac registers, offset, and gain register.

    Is there any chance that the gain-A bit or gain-B bit on the configuration register is changed in program?  If so, the configuration register automatically reloads the factory-trimmed code into the Offset DAC-A register for the new gain-A setting.  Therefore, once you program the gain you will have to re-program the offset DAC-A register again.  This information is listed in page 68 of the DS.  Please also look at Table 5 and Table 6 of the DS to look at examples of gain, offset and their relation with DAC output voltage.

    Also keep in mind that the analogue outputs must not go beyond the specified range shown in the Analog Outputs section of the DS. 

    For verification, please specify the ramp range and offset range you are trying to achieve.

    My answers from today:

    The pictures above don't run any offset-A value. They are set to the described value and the loop is running the dac- value only.

    I extended my program to read the registers 0= CONFIG, 2=GPIO, 3=OFFSET-A, 4=OFFSET-B and 8=DAC-0 and print them. After power up the contence is: 0=8000, 2=E000, 3=8000, 4=8000, 8=0000 where the CONFIG, GPIO and DAC-0 looks good but not the OFFSET registers. After setting gain of 4 the reigsters look like: 0=8180, 2=E000, 3=8000, 4=8000, 8=0000 where no change to the OFFSET registers has happen but CONFIG contains the gain bits.

    Running the OFFSET-A loop with the registers read each time after setting the OFFSET-A they look like:

     0; 0=8180, 2=0000, 3=8000, 4=8000, 8=0000; -32768

     1; 0=8180, 2=2000, 3=8800, 4=8000, 8=0000; -30720

     2; 0=8180, 2=4000, 3=9000, 4=8000, 8=0000; -28672

     3; 0=8180, 2=6000, 3=9800, 4=8000, 8=0000; -26624

     4; 0=8180, 2=0000, 3=A000, 4=8000, 8=0000; -24576

     5; 0=8180, 2=2000, 3=A800, 4=8000, 8=0000; -22528

     6; 0=8180, 2=4000, 3=B000, 4=8000, 8=0000; -20480

     7; 0=8180, 2=6000, 3=B800, 4=8000, 8=0000; -18432

     8; 0=8180, 2=0000, 3=C000, 4=8000, 8=0000; -16384

     9; 0=8180, 2=2000, 3=C800, 4=8000, 8=0000; -14336

    10; 0=8180, 2=4000, 3=D000, 4=8000, 8=0000; -12288

    11; 0=8180, 2=6000, 3=D800, 4=8000, 8=0000; -10240

    12; 0=8180, 2=0000, 3=E000, 4=8000, 8=0000;  -8192

    13; 0=8180, 2=2000, 3=E800, 4=8000, 8=0000;  -6144

    14; 0=8180, 2=4000, 3=F000, 4=8000, 8=0000;  -4096

    15; 0=8180, 2=6000, 3=F800, 4=8000, 8=0000;  -2048

    16; 0=8180, 2=0000, 3=0000, 4=8000, 8=0000;      0

    17; 0=8180, 2=2000, 3=0800, 4=8000, 8=0000;   2048

    18; 0=8180, 2=4000, 3=1000, 4=8000, 8=0000;   4096

    19; 0=8180, 2=6000, 3=1800, 4=8000, 8=0000;   6144

    20; 0=8180, 2=0000, 3=2000, 4=8000, 8=0000;   8192

    21; 0=8180, 2=2000, 3=2800, 4=8000, 8=0000;  10240

    22; 0=8180, 2=4000, 3=3000, 4=8000, 8=0000;  12288

    23; 0=8180, 2=6000, 3=3800, 4=8000, 8=0000;  14336

    24; 0=8180, 2=0000, 3=4000, 4=8000, 8=0000;  16384

    25; 0=8180, 2=2000, 3=4800, 4=8000, 8=0000;  18432

    26; 0=8180, 2=4000, 3=5000, 4=8000, 8=0000;  20480

    27; 0=8180, 2=6000, 3=5800, 4=8000, 8=0000;  22528

    28; 0=8180, 2=0000, 3=6000, 4=8000, 8=0000;  24576

    29; 0=8180, 2=2000, 3=6800, 4=8000, 8=0000;  26624

    30; 0=8180, 2=4000, 3=7000, 4=8000, 8=0000;  28672

    31; 0=8180, 2=6000, 3=7800, 4=8000, 8=0000;  30720

    32; 0=8180, 2=0000, 3=7FFF, 4=8000, 8=0000;  32767

    Just OFFSET-A changes like it should be. This are the register values which corrwespond to the picture 1 offset. The position in time on the screen can be calculated by time := 20ms + count × 5ms (count = left column).

    Now your final request: I should run loops of offset and dac values. To have it more comparable to the latest picturs the loops are running 17 values from -32768 (0x8000) up to +28672 (0x7000)  in steps of 4096 (0x1000) and finalizes with 32767 (0x7FFF). The DAC-0 output voltage of gain 4 for should look by theory like:

    and appears on the oscilloscope when each step takes 5ms with an over all time of 17×17×5ms = 1445ms like:

    I read the registers back each setup but I don't want to bother you with 289 lines of values which are all ok. I just show a reduced table:

    DAC auto measurement offset/value signed

    Offset;Dac;Registers

     0;  0; 0=8180, 2=0000, 3=8000, 4=8000, 8=8000; -32768

     0;  1; 0=8180, 2=0000, 3=8000, 4=8000, 8=9000; -28672

     0;  2; 0=8180, 2=0000, 3=8000, 4=8000, 8=A000; -24576

     0;  3; 0=8180, 2=0000, 3=8000, 4=8000, 8=B000; -20480

     0;  4; 0=8180, 2=0000, 3=8000, 4=8000, 8=C000; -16384

     0;  5; 0=8180, 2=0000, 3=8000, 4=8000, 8=D000; -12288

     0;  6; 0=8180, 2=0000, 3=8000, 4=8000, 8=E000;  -8192

     0;  7; 0=8180, 2=0000, 3=8000, 4=8000, 8=F000;  -4096

     0;  8; 0=8180, 2=0000, 3=8000, 4=8000, 8=0000;      0

     0;  9; 0=8180, 2=0000, 3=8000, 4=8000, 8=1000;   4096

     0; 10; 0=8180, 2=0000, 3=8000, 4=8000, 8=2000;   8192

     0; 11; 0=8180, 2=0000, 3=8000, 4=8000, 8=3000;  12288

     0; 12; 0=8180, 2=0000, 3=8000, 4=8000, 8=4000;  16384

     0; 13; 0=8180, 2=0000, 3=8000, 4=8000, 8=5000;  20480

     0; 14; 0=8180, 2=0000, 3=8000, 4=8000, 8=6000;  24576

     0; 15; 0=8180, 2=0000, 3=8000, 4=8000, 8=7000;  28672

     0; 16; 0=8180, 2=0000, 3=8000, 4=8000, 8=7FFF;  32767

     1;  0; 0=8180, 2=2000, 3=9000, 4=8000, 8=8000; -32768

     1;  1; 0=8180, 2=2000, 3=9000, 4=8000, 8=9000; -28672

     1;  2; 0=8180, 2=2000, 3=9000, 4=8000, 8=A000; -24576

    ...

     1; 15; 0=8180, 2=2000, 3=9000, 4=8000, 8=7000;  28672

     1; 16; 0=8180, 2=2000, 3=9000, 4=8000, 8=7FFF;  32767

     2;  0; 0=8180, 2=4000, 3=A000, 4=8000, 8=8000; -32768

     2;  1; 0=8180, 2=4000, 3=A000, 4=8000, 8=9000; -28672

    ...

     2; 15; 0=8180, 2=4000, 3=A000, 4=8000, 8=7000;  28672

     2; 16; 0=8180, 2=4000, 3=A000, 4=8000, 8=7FFF;  32767

     3;  0; 0=8180, 2=6000, 3=B000, 4=8000, 8=8000; -32768

     3;  1; 0=8180, 2=6000, 3=B000, 4=8000, 8=9000; -28672

    ...

    ...

    ...

    14; 15; 0=8180, 2=4000, 3=6000, 4=8000, 8=7000;  28672

    14; 16; 0=8180, 2=4000, 3=6000, 4=8000, 8=7FFF;  32767

    15;  0; 0=8180, 2=6000, 3=7000, 4=8000, 8=8000; -32768

    15;  1; 0=8180, 2=6000, 3=7000, 4=8000, 8=9000; -28672

    15;  2; 0=8180, 2=6000, 3=7000, 4=8000, 8=A000; -24576

    ...

    15; 14; 0=8180, 2=6000, 3=7000, 4=8000, 8=6000;  24576

    15; 15; 0=8180, 2=6000, 3=7000, 4=8000, 8=7000;  28672

    15; 16; 0=8180, 2=6000, 3=7000, 4=8000, 8=7FFF;  32767

    16;  0; 0=8180, 2=0000, 3=7FFF, 4=8000, 8=8000; -32768

    16;  1; 0=8180, 2=0000, 3=7FFF, 4=8000, 8=9000; -28672

    16;  2; 0=8180, 2=0000, 3=7FFF, 4=8000, 8=A000; -24576

    16;  3; 0=8180, 2=0000, 3=7FFF, 4=8000, 8=B000; -20480

    16;  4; 0=8180, 2=0000, 3=7FFF, 4=8000, 8=C000; -16384

    16;  5; 0=8180, 2=0000, 3=7FFF, 4=8000, 8=D000; -12288

    16;  6; 0=8180, 2=0000, 3=7FFF, 4=8000, 8=E000;  -8192

    16;  7; 0=8180, 2=0000, 3=7FFF, 4=8000, 8=F000;  -4096

    16;  8; 0=8180, 2=0000, 3=7FFF, 4=8000, 8=0000;      0

    16;  9; 0=8180, 2=0000, 3=7FFF, 4=8000, 8=1000;   4096

    16; 10; 0=8180, 2=0000, 3=7FFF, 4=8000, 8=2000;   8192

    16; 11; 0=8180, 2=0000, 3=7FFF, 4=8000, 8=3000;  12288

    16; 12; 0=8180, 2=0000, 3=7FFF, 4=8000, 8=4000;  16384

    16; 13; 0=8180, 2=0000, 3=7FFF, 4=8000, 8=5000;  20480

    16; 14; 0=8180, 2=0000, 3=7FFF, 4=8000, 8=6000;  24576

    16; 15; 0=8180, 2=0000, 3=7FFF, 4=8000, 8=7000;  28672

    16; 16; 0=8180, 2=0000, 3=7FFF, 4=8000, 8=7FFF;  32767

    And finally to make sure we reproduce I just zoom into the last picture. First time at position zero where you can see the first two loops with offset of -32768 (0x8000) and -28672 (0x9000):

    A 2nd zoom at the point in time after 340ms where the offset jumps from 0xB000 to 0xC000 at the trigger position and further to 0xD000 ms after the middle of the screen.

    Beside the resolution of steps of 4096 instead of 2048 the pictures look the same as above where i set a fixed offset for a single dac loop. Also the higher step of the offset can be seen 5ms after the middle of the screen as it can be seen for the dac when it steps from 0xC000 to 0xD000 at position 45ms or at 130ms.

    Over all the hardware does what it did already the last weeks and even different ways of generating output values show always non linear behavior. Whats going on inside the chips? Whats wrong with the silicon? I will not believe that the my interface or the program will have a malfunction.

    With Kind Regards

    Harald Hellmann



    Count, Unipolar, Hex,   Bipolar, Twos compl., Twos compl.    0,        0, 0x0000,      0,      0x8000,   -32768    1,     2048, 0x0800,   2048,      0x8800,   -30720    2,     4096, 0x1000,   4096,      0x9000,   -28672    3,     6144, 0x1800,   6144,      0x9800,   -26624    4,     8192, 0x2000,   8192,      0xA000,   -24576    5,    10240, 0x2800,  10240,      0xA800,   -22528    6,    12288, 0x3000,  12288,      0xB000,   -20480    7,    14336, 0x3800,  14336,      0xB800,   -18432    8,    16384, 0x4000,  16384,      0xC000,   -16384    9,    18432, 0x4800,  18432,      0xC800,   -14336   10,    20480, 0x5000,  20480,      0xD000,   -12288   11,    22528, 0x5800,  22528,      0xD800,   -10240   12,    24576, 0x6000,  24576,      0xE000,    -8192   13,    26624, 0x6800,  26624,      0xE800,    -6144   14,    28672, 0x7000,  28672,      0xF000,    -4096   15,    30720, 0x7800,  30720,      0xF800,    -2048   16,    32768, 0x8000, -32768,      0x0000,        0   17,    34816, 0x8800, -30720,      0x0800,     2048   18,    36864, 0x9000, -28672,      0x1000,     4096   19,    38912, 0x9800, -26624,      0x1800,     6144   20,    40960, 0xA000, -24576,      0x2000,     8192   21,    43008, 0xA800, -22528,      0x2800,    10240   22,    45056, 0xB000, -20480,      0x3000,    12288   23,    47104, 0xB800, -18432,      0x3800,    14336   24,    49152, 0xC000, -16384,      0x4000,    16384   25,    51200, 0xC800, -14336,      0x4800,    18432   26,    53248, 0xD000, -12288,      0x5000,    20480   27,    55296, 0xD800, -10240,      0x5800,    22528   28,    57344, 0xE000,  -8192,      0x6000,    24576   29,    59392, 0xE800,  -6144,      0x6800,    26624   30,    61440, 0xF000,  -4096,      0x7000,    28672   31,    63488, 0xF800,  -2048,      0x7800,    30720   32,    65535, 0xFFFF,     -1,      0x7FFF,    32767

  • Sorry, I don't know why the last list of values appered after i signatured my post.
    Harald Hellmann
  • Hi,

    it's once more I. I just want to get even more data to figure out the problems we have. First of all from today is running a higher resolution for setting OFFSET-A. I used 513 steps each but the last 128 high for 8ms per step. Therefor loop is running -32768 (0x8000), -32640 (0x8080), -32512 (0x8100), ... up to ... 32512 (0x7F00), 32640 (0x7F80) and finally 32767 (0x7FFF).

    Please keep an eye on y-divisions. It's 600mV to have the range of 0..4096mV better spread. But the oscilloscope resolution is 8bits only. Therefore we can't see each of the 513 steps. Lets see a zoom into the first half of time.

    And one more zoom into the range from 800ms on.

    We did it a lot of times and the data will perfectly reproduced. The reference stability was checked during data transfer and over  all the time and looks very fine. Trying the other dac for OFFSET-B looks like:

    The range of non linearity is very close to the range of OFFSET-A but the output voltage differs.

    Let's see the DAC-0 voltage when running the high resolution. Gain is set to 4 and OFFSET-A was set to 0xC000.

    It looks very close to the OFFSET-A dac. Even a zoom does it.

    A more details zoom looks like:

    What is DAC-1 doing? Here's the answer using the same conditions like gain of 4 and-A of 0xC000:

    And DAC-5?

    Even zoomed into the first half of values:

    Or just into the range of non linearity:

    All measurement were done reading the registers back. These were carefully checked and OK.

    A second board with a second DAC8218 behaves the same way. The DAC is labeled with the TI symbol followed by OBA445TG4 in the first line and the second line contains: DAC8218S.

    Please help!

    With Kind Regards

    Harald Hellmann

  • Howdy Harald,


    Thank you for the information, but I'm having a hard time following the data so I think it would be a better solution if we change our debugging procedure and focus on a single point of measurement.

    But before we get to this, I noticed some ESD protecting diodes on the output pins of the schematic.  Can you remove this from the output connection and retry your ramp.  If this does not solve the issue you can help us debug by providing the below.

    In the requests below, please provide the gain, reference, supply voltage, and output voltage for the requested digital writes (keep offset 0):

    Write  0x9000 (-28672), and measure output voltage of DAC
    Write  0x9800, (-26624), and measure output voltage of DAC

    Write  0xD000, (-12288), and measure output voltage of DAC

    Write  0xE000,  (-8192), and measure output voltage of DAC


    This will help me verify the LSB step size as well as help keep a simple approach to solving the linearity part of this issue.

    Best Regards,

    Matt

  • Hello Matt,

    thanks for keep going. I can imagine that it is hard to follow but I will do what you want. Even if I think you are looking for the wrong focus.

    Our ESD diodes have an operation voltage of ±14V and don't influence our signal. But as you wished we removed them just to make sure no influence at all.

    We have measured the following voltages at a gain of 4:

    Value DAC-0 Vnoisepp Vnoiserms
    0x8000 0.042V 15mV 1.8mV
    0x8800 0.937V 16mV 2.0mV
    0x9000 1.798V 18mV 2.1mV
    0x9800 2.632 20mV 2.2mV
    0xD000 7.6V 80mV 12mV
    0xD800 10.02V 400mV 50mV
    0xE000 11.88V - -

    where at each value the power supply was checked with IOVdd+DVdd = 3.344V, AVss = +11.92V, AVdd = -12.02 and the OFFSET Pin = 0.040V.

    I don't think you should calculate any LSB. You can trust our oscilloscope which shows you the non linearity because we are a ISO 13485 certified company where measurement equipment has to be calibrated. Much more important than the LSB step is effect more in the middle of the range. We have measured some more values than you requested to have been measured what the oscilloscope has been shown:

    Value DAC Vnoisepp Vnoiserms
    0xD400 7.99V 130mV 18mV
    0xD500 7.95V 100mV 13mV
    0xD600 8.48V 180mV 29mV
    0xD700 8.28V 150mV 25mV
    0xD780 8.61V 135mV 21mV
    0xD880 8.70V 115mV 16mV
    0xD900 8.41V 120mV 19mV
    0xD980 8.74V 117mV 17mV
    0xDA00 9.58V 325mV 45mV
    0xDB00 8.71V 190mV 28mV

    This should be impossible by a resistor-string DAC. Therefore don't calculate LSB steps. Ask the chip designers and production what could be broken. We have build our third board which behaves non linear in this range too.

    With Kind Regards

    Harald Hellmann

  • Hello Matt,
    just to substantiate my wish to talk to the designers or to production. Wether a soft reset nor a change of gain set the offset registers to the value of the data sheet or ±3 LSB close to it. It will always be set to 0x8000.
    With Kind Regards
    Harald Hellmann
  • Howdy Harald,

    Given that this is not typical behavior, I'm currently working on a setup that matches your current system.  The goal is to try to replicate the behavior you are experiencing.

    The incorrect offset register reads lead me to believe that either your power sequencing of the device is incorrect, or the writes to the device may be incorrect

    As listed in the datasheet (page 44), for proper power-on initialization of the device, IOVDD and the digital pins must be applied before or at the same time as DVDD.  After these supplies AVDD should fully ramp before or at the same time as AVSS.  The REF-x should be applied last.  Optionally, REF-X can be applied before AVSS, but not before AVDD.

    To verify the writes, please provide a zoom in capture of one DAC register write, including CS, SCLK, SDI, and SDO.  The written address with data will also be good to compare against the actual signals.  It is important that one transaction is displayed for view-ability purposes.

    I will update you once I have results..

    Best Regards,

    Matt

     

  • Howdy Harald,

    I think I stumbled upon your issue, and the behavior you are noticing may be a result of violating the absolute maximum ratings listed in page 2 of the DAC8218 DS.  The maximum voltage of REF-A and REF-B must be DVDD.  If the reference voltages exceed DVDD they can activate the internal ESD protective diodes of the device and sink large current, which can damage the device and affect performance.

    ABSOLUTE MAXIMUM RATINGS for REF-A/B:

    Please verify that the REF-A, REF-B pins are equal to or less than DVDD, as you previously mentioned a value of 4.096V for the reference, and just in the post above listed DVDD as 3.34V.  Please increase DVDD to 5V for correct operation while maintaining the conditions listed in the absolute maximum ratings table.

    For reference I've included my Lab Result, which was generated with the DAC8218EVM and DXP software. My supplies were configured as:

    DVDD/IOVDD:5V, REF-A:4.009V, AVDD=14V, AVSS=-14V. Gain set to default 6x.

    Frequency of saw-tooth waveform: 1kHz.  CH1: Vout0

    Best Regards,

    Matt

  • Hello Matthew,

    thank you for the last hint and I have to apologize. I never missed one of the absolute maximum ratings.

    Therefore we removed the old reference and checked the functionality temporarily with a reference of 3.3V because IOVdd and DVdd is very hard tight to 3.3V. By theory it should look like:

    and we could it measure as:

    which looks perfect as it should be. Even a high resolution ramp from -9.9V up to +9.9V looks now like:

    All the other stuff worked already fine. I ordered immediately a REF5030 to put it on the PCB. Unfortunately there is no REF5033 available from TI. Therefore I will have an output range from -9.0V up +9.0V which will be fine for the demonstration. Maybe we have to change power supply of our board.

    Could you already check for the difference of absolute maximum ratings and power on sequence which I found? Just to remember. Absolute maximums says 'IOVdd <= DVdd < 6V' and Power-on reset sequencing says: 'IOVdd must be applied before or at the same time as DVdd'. At the same time is covered by IOVdd = DVdd. What else is ok?

    With Kind Regards and I owe you one

    Harald Hellmann

  • Howdy Harald,

    That's great news, glad you were able to get it up and running.  Regarding absolute maximum ratings, as long as your solution adheres to the table found on page 2 of the DAC8218 datasheet everything should operate correctly, and as specified in the datasheet.

    The power-on sequence is found on page 44 of the datasheet.  As you've previously stated, you can reduce the amount of power supplies required for digital by connecting both IOVDD and DVDD together. And as you've indicated both supplies have an absolute maximum rating of 6V.  It is important to note that when designing around absolute maximums it is generally good practice to add some overhead or margin away from the max value to ensure that the supply never exceeds this maximum due to noise or any other possible interferences.

    When powering, the first supplies to ramp must be IOVDD/DVDD, which should ramp together in this case since connected.  The next supply to fully ramp is AVDD, then AVSS, with reference (REF-X) last.  Optionally,  we have found through experimentation that REF-X supplied before AVSS, but after AVDD, is also acceptable.


    Best Regards,

    Matt

  • Hello Matthew,
    thank you for the explanation. That's the way I understand the datasheet so far. My question came up on a different design. If I want to run IOVdd = 3.3V because of my µC I/O and DVdd = 5.0V because to be higher than the reference. How should I make sure the absolute maximum condition IOVdd <= DVdd, when IOVdd comes faster up than DVdd? Or the other condition IOVdd before DVdd but DVdd comes up faster than IOVdd?
    With Kind Regards
    Harald Hellmann
  • Howdy Harald,

    In this case it is acceptable to power IOVDD before DVDD, just ensure that the delay between both supplies is minimal. Design has commented that a delay in the tens of micro-seconds is preferable.

    Best Regards,
    Matt