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.

DDC316: DDC316 Component Failure

Part Number: DDC316

Hello,

On one of my prototype boards, I experienced failure of one of the DDC316 components. It pulls an additional ~100mA at the 12V benchtop supply (which is stepped down to 3.3V and 5V through isolated power supplies), and gets very hot to touch. The excess load is likely on the analog side of the part, as the 5V supply is also slightly warmer than normal, while there is no perceptible difference on the 3.3V supply. When trying to control and communicate to the part, I never get a pulse on nDVALID. It did work correctly when the board was first being used, though the exact time of failure can't be easily determined since we were mostly using another DDC316 on the board and the supply current was not being constantly monitored. I can't rule out thermal stress, because we have reworked the photodiode on that channel multiple times for unrelated reasons. The anode side of the diode only has the pad and a thin (4 mil) copper trace going - of course kept as short as possible - going into into the DDC316 input. While the iron was not kept on the pad for very long, the DDC316 is still the closest large heat sink.

One thing I did want to make sure was correct is that I am driving the CONV pin for an acceptable duration. I have been extending the integration time out to 40,000 us while lowering CLK to 1 MHz. The specification calls out a maximum integration time as 1,000 us - while CLK is at 40 MHz. It also calls out on another line that the integration time can be a maximum of 40,000 CLK periods. On yet another line, it states that the maximum allowed CLK period is 1000 ns. This suggests that 40,000 us integration time when CLK is at 1 MHz should be acceptable. Was my interpretation of the integration time limitations of the component incorrect and putting the component at risk?

Do you have any other insight into what sort of improper handling or use could cause this? This is a board that went through software development, and any number of erroneous control signal states could have occurred during interim stages of software development. If there are specific scenarios we should add safety features into our software to avoid, that would be good information to have.

  • Hi Francesco,

    I have to say that I like how you looked at things and the level of details on your post. Honestly as you can imagine I think it is hard to know how much heat is too much heat. Don't have experience on that except that usually devices (in general) can take quite a bit of beating (although of course, if there has been quite a bit of re-work maybe...). I am curious and will ask our quality folks if I there is some rule of thumb...

    What I am quite sure is that you can't damage the device by any kind of digital operation (clocking, register programming...). I would be very surprised but will ask the designer to see if he can think of anything. I assume that the high power consumption is even under normal operation (from whatever interpretation of the spec). 1ms as CONV sounds very short limit to me and other DDCs can go longer (but this is one of the fastest, so maybe). Let me ask also that.

    If you want, feel free to write me to ddcxxx-support@list.ti.com and will try to get you a free sample (didn't check we have) to replace instead of that one, so you can see if this happens again...

    Wil be back,

    Edu

  • Hi again,

    Checked with designer and he recalls that the speed limits would be related to leakage on the capacitors, so, more a performance related issue than any risk of damage. That shouldn't be the cause of the issue you are seeing.

    About the speed limits, I would go with the ones on the page 6 (which depend on the speed mode). Again, don't think those are hard stops but more indicate the point where a gradual performance degradation may start.

    Regards,
    Eduardo
  • I did notice an increase in noise counts significantly beyond the datasheet's spec when I ran at 40ms integration time, and it went back within spec after I went back to 1ms, so that makes sense to me. I can recover the bits to an extent with averaging, but will be staying with 1ms or less for as long as it will meet resolution requirements. But good to know the CONV timing and configurations of the other IO can't damage the part. Unless it occurs again on another board that is treated more gently, I expect this is just the result of the reworks.
  • Hi Francesco,

    Just closing on the rework stuff, even if just as a curiosity...

    Got this document: 

    http://www.ti.com/lit/an/slva439a/slva439a.pdf

    Of course, this applies more to removing the component itself, not a neighboring re-work, but still thought I would pass it :)

    Regards,
    Edu