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.

ADS1112: Intermittent Failure Mode where All Ports Read Zero

Part Number: ADS1112

I am using ADS1112 in a proven design.  I have one sample of ADS1112 that goes into a failure mode where all channels read as zero with respect to AIN3.  Power cycling resolves the failure. It happened twice.  I have swapped the part for a new one, leaving everything else the same.  The two times I've seen this failure mode occurred within 24 hours of use.  

If it occurs again with a fresh part, I'll know there's something else wrong causing the ADS1112 to latch up.  If not, there must be something peculiar about this one sample of ADS1112.  

My question is if anyone has heard of a failure mode where the ADC reads 0 in all registers but that can be resolved by power cycling.  

  • Hello,

    Please let me know what happens with the ABA swap you performed, this was a good strategy. 

    As for possibilities of device registers being reset, the power level would be the most relevant factor. If the device browns out, where a significant dip in the power occurs but not a total zero of the power supply. For this device, when it powers up, it automatically performs a reset. and sets all of the bits in the configuration register to their default settings, a brown out effect could initialize a reset process.

    Regards

    Cynthia

  • Thanks.  I did not connect a scope or I2C sniffer, so I was trusting what the software told me.  The software is supposed to be setting the config register with each read and then checking the Ready bit before reading the data register, but I cannot confirm that's happening.  

    Since I replaced the IC, the problem has not occurred.  Is there any way TI test it or do some analysis if I sent it to a TI lab?

  • That is great to hear. 

    I would suggest to run the new device for sometime before concluding that the original device was the source of the issue. If the original device was damaged somehow that resulted in this behavior, this new device could result in the same. 

    Confirming communications is also a good idea, the methods you mentioned would help to confirm that the firmware is in fact communicating as expected. 

    You can reach out to your field/sales TI representative. If you do not have one, I can put you in contact without someone in your area. They will be able to help you file the correct information to initiate a return. Although, I believe that if the device was damaged during your use, this will not really be much of help, but your representative would know best. 

    Regards

    Cynthia

  • I would suggest to run the new device for sometime before concluding that the original device was the source of the issue. If the original device was damaged somehow that resulted in this behavior, this new device could result in the same. 

    I swapped the part with a part from my supply in the lab, making no other changes.   -->  We have not seen this issue since.

    The problem has occurred on another system.  As before, power cycling resolves the issue. 

    Hypothesis: This board build used a bad reel of ADS1112.  They bought some parts from brokers.  The parts could be counterfeit.

    My plan is to swap the ADC chip with another one from this same board build.  Then, if it happens again, I will swap the part with an ADC chip from my supply in the lab, which I've never had a problem with.  If the problem does not occur, this points to the recent build having used a bad batch of chips.  

    Could I sent the parts to TI for testing/analysis?  

    You can reach out to your field/sales TI representative. If you do not have one, I can put you in contact without someone in your area. They will be able to help you file the correct information to initiate a return. Although, I believe that if the device was damaged during your use

    I used to, but I'm not sure who it is anymore.  Could you look it up?  

    I could provide the part that's showing the issue and an never-powered part from the same build.  I would rather not provide a good part from my supply because they are hard to come by now.  Grinning

  • Charles, 

    That is very unfortunate, if they do turn out to be counterfeit parts. Given the current state, it is possible that they are. 

    Your plan sounds very good, this would help to confirm performance. looking at the parts, do they show similar package markings? Would you please send a picture of the top markings of the possible counterfeit device?

    I have contacted a field engineer about your situation nd decide what best steps to move forward. 

    Regards

    Cynthia 

  • Your plan sounds very good, this would help to confirm performance. looking at the parts, do they show similar package markings? Would you please send a picture of the top markings of the possible counterfeit device?

    Here is the part.

    It turns out the CM bought this part 2.5 years ago from Digikey, not brokers.  Date code = Aug-2018.  Lot code = 8857351ML8.

    I think it's a longshot that it's counterfeit or that there's any problem with the lot, but I appreciate your investigating.

  • I have contacted a field engineer about your situation nd decide what best steps to move forward. 

    Is this the support engineer for our geographic area or for this product line?  Can you send me their contact info?  It would be good for me to know who our field sales rep is.  

  • Charles, 

    Thank you for this information, I will look into it. I will get back to you 

    E2E post are supported by product lines, that is me. I have asked a regional field contact to reach out to you to open that communication channel. 

    Regards

    Cynthia