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.

DAC3171 7-bit Interface Mode

Other Parts Discussed in Thread: DAC3171

Customer is using DAC3171 and trying to use 7-bit interface mode.When they read config6:bits 7-0, the read 0x90 which indicates only 14-bit interface mode is supported. They are clearing config1:bit13 to tr yto put the device in 7-bit interface mode.

Why are they not reading 0x10 from config6:bits7-0 (they read 0x90)? Can they do anything to change what value they read here?

Are there DAC3171 devices that only support 14-bit interface mode and not 7-bit interface mode?

We are using datasheet SLAS959A.

The markings on the device are:

DAC3171I

TI 33J

P3D6 G4

  • Hi,

    I have a DAC3171 EVM in hand that came straight from stock, and I also read 0x90 for that register.  So it looks like the fuse for forcing full word interface was blown in production test when it should not have been.  I have the test engineer opening the test program in the morning to take a look at why this is.

    I also had the characterization engineer look at the EVM with me, and once that fuse bit is blown, that is all that can be done.  There is no way to un-blow the fuse. 

    We will look into what happened and what we can do about it, and I will come back to you with the findings.

    Regards,

    Richard P.

  • I also just ran into this exact same issue with some DAC3171s I recently purchased from Digikey. I'm also seeing the fuse register reading 0x0090 instead of 0x0010. I finally found the issue after going through the registers with a fine tooth comb after wasting a week of time trying to figure out why the lower 7 bits were not influencing the output. Did you ever find a fix?
  • The DAC3171 parts were not enabled for 7-bit mode properly because fuses were incorrectly blown by TI during production testing. They have fixed their process and new parts now support he right setting. This was fixed around August 2015.

  • There are obviously still bad parts in the wild on vendor shelves, since the parts we bought were purchased around the June/July 2016 time frame, and register 6 indicates that the fuses are blown to prevent 7-bit operation.  The bad parts should have been recalled, but they obviously either were not or they missed some. This is no laughing matter, as we're out thousands of dollars due to defective boards.  

  • I am having this same issue. Parts also purchased from DigiKey in Mid/late 2016. I've submitted a request for resolution from TI and will be submitting something to DigiKey as well.

    John, were you able to get any resolution?

    Are these parts, and our boards toast?
  • Matt, sorry to hear you're having the same issue. Unfortunately since fuses were physically blown at the factory, apparently, there was no workaround except to rework the parts on the boards with replacements. TI did replace the ten parts we bought for our prototypes free of charge from their sample stock once they verified they had some good ones (took over a month to get them though, as I recall), but they did not give me an answer on where I could buy additional known good parts, so we ended up cutting our losses and are working on redesigning our boards to use DACs from another manufacturer. The replacement DACs did seem to work as advertised, so if you can manage to get ones that were fused correctly you should be fine. I would definitely recommend testing (by reading the fuse registers) samples from any batches you buy from now on prior to paying to have them assembled.

    I notified TI of the issue and supplier in late Aug 2016, so hopefully they actually worked with Digikey to remove the parts from circulation in a timely fashion. If you got your parts much later than that and you have a lot of populated boards, you might be able to work with your legal dept. and recoup some costs from whomever dropped the ball on getting those things out of circulation.
  • Matt,

    I am also sorry to hear that you got a hold of the older stock.  That is not supposed to happen, and was not supposed to have happened for John either. 

    I just spoke with our internal quality person.   We will get replacement devices to you. 

    The original source of the error was pretty simple, and the fix was simple.   The 12bit and 10bit versions of this device will not support the dual 7bit bus mode, and thus there is a production fuse to disallow this mode on devices that are not supposed to support it.  But the fuse got set for the whole family of devices, and it did not become apparent until someone tried to use the dual bus 7bit mode.   Turns out most early customers of the device used the 14bit bus mode and the error was not apparent.   When the error became known, we fixed the production test program and scrapped all internal work in process inventory. Flushed it.   And started a new production lot of material to get the product pipeline filled up again.   But the material that had already gotten outside the TI doors had to be pulled back and replaced with new material.   Which was done or at least was ordered to be done - so there should not have been any old stock sitting on a shelf anywhere that you should have gotten a hold of. 

    Our quality person will want to contact you about getting replacement material to you. 

    Regards,

    Richard P.

  • Richard,

    I agree it shouldn't have happened...the question I have is: why did it happen even though it shouldn't have? What steps were taken to ensure the device met quality standards in both advertised modes prior to leaving the factory? It was pretty apparent to me with a sine wave coming out that it wasn't meeting SFDR/SNR targets for even an 8-bit device. That indicates to me that maybe the quality assurance process could be improved, since that's a basic check that should be done on random samples, at a minimum, in the operating modes it was advertised to support.

    Also, the datasheets continued to advertise it for a purpose that it was potentially unsuited for, which in my opinion should have been assumed until all defective vendor inventory was returned and accounted for. Why wasn't an advisory notice immediately placed on the datasheets and your product page stating that it might not work in 7-bit mode due to a factory error? At least then I wouldn't have wasted weeks of time and effort trying to troubleshoot a complex system.

    We incurred significant rework and time penalty costs due to this error and the time it took to get replacements (many weeks), which were not compensated by the replacement of a few defective parts, so while I appreciate the apology, it doesn't really make up for the losses.

    John
  • Thank you Richard. Looks like TI will be replacing the parts for us, but as John says this shouldn't have happened. Unfortunately it would seem that I cannot be guaranteed that we will not continue to get bad parts from a distributor (like Digikey). Given the repeated documented problem, I'm not sure why this can't be corrected...

    Going forward, if we continue to use this part, it seems like we'd have to carefully manage the supply chain to prevent a bad part from slipping in. I'm hoping TI can provide date code information so that there can be a screen set up for bad parts (I've been told by the TI rep that he's looking into this). "Good" and "bad" date codes would be a very good thing to publish in an errata, at a minimum...

    -Matt
  • Richard,

    We unfortunately had to order more of these DAC3171s to populate another series of boards, and we just got another bad batch from Digikey (after they had supposedly been recalled).  Luckily, I tested an IC from the batch first this time, and found them to be reporting the same incorrectly blown fuse that forces the device into full-word interface only mode (register 6 = 0x4090), and performance is consistent with a 7-bit DAC.  At this point, I'm extremely disappointed that this issue has not been corrected in such a long period of time.  I notified your company of this issue last fall, yet there are still bad parts floating around at MAJOR distributors. As of the time of this post, I can find no advisory or anything on your website to indicate that certain devices may not be suitable for the 7-bit interface advertised.

    I would appreciate a call from someone in your senior management (I'm thinking the VP of the division responsible for DACs would be appropriate) to discuss this issue, as I have no confidence that it is being resolved effectively by whoever is working on it, if anyone.  I attempted to email the QA engineer I had worked with (Bernard) several months ago regarding this issue to re-confirm that all the defective parts had been received back, and never received a response.

    John

  • Hi,

    yes, I will take this up the chain.  I will bring this to the attention of our quality person (we have a different person from last time, so I want him to be fully aware of the history here) and also start with our product line manager. 

    Regards,

    Richard P.

  • Hello,

    We also had to order more DAC3171. Earlier this year, we were told from to order direct from the TI store to ensure the correct part is received. We have done so, and TI passed our order on to DigiKey for fulfillment. DigiKey was the distributor we first received bad parts from.

    We have no means to test these parts prior to installing them, and will not install them until we can get a guarantee from TI that these are fused properly. Please let me know what DATE CODEs are valid so we can confirm the parts we received are valid.

    -Matt
  • Matt,

    The break-out datecode (new material w/ correct trim) are 1523.

    regards, Jay
  • Jay,

    The markings on our parts are:

    DAC3171I

    TI 62J

    P88K G4

    Please advise how to match the date code above with these markings.

    Thank you,

    Matt Thomas

  • Matt,

    TI 62J
    P88K G4
    has datecode 1606. It is safe to use.

    regards, Jay
  • Thank you very much!