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.

VDDIO, VDDA short TMS320F2812

Other Parts Discussed in Thread: TMS320F2812

I have a very similar problem as discussed in https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/394313 , and https://e2e.ti.com/support/microcontrollers/c2000/int-c2000/f/175/t/519686 .  On a failed device, the 3.3V rail reads ~20-ohms, the 1.9V rail ~4-ohms. 

The power sequence of 3.3V ramping first, followed by 1.9V only after the 3.3V rail is > 2.5V is being adhered to, so I don't believe the ON sequencing is an issue.  But what about power-OFF sequence? 

Also, as previous post pointed out, having a voltage present on an IO or ADC pin, and no current-limit protection, is described in the 'F28335, but I don't see it discussed in the 'F2812 datasheet.  Does the same condition also apply for this processor?

I'm not sure what additional information will assist with troubleshooting this failure.  What other info might you need to help determine the cause of failure?

In addition to the low resistance on these power rails, when power is applied to a failing device, the F2812 is constantly RESETing at about a 250Ha rate.  It is also outputting a CLK of about 4MHz. 

~Leonard   

  • Hi Leonard,

    Q: But what about power-OFF sequence?
    A: Power-up and Power-down sequencing requirements are stated in the TMS320F2812 datasheet in section 6.8. These requirements are W.R.T. holding the device in reset and preventing the IO pins from glitching or flash from running in an undefined power state. As long as the voltages on the supply pins are within in the acceptable range on this device, the ramping should not cause any damage to the device.

    Q: Does the same condition also apply for this processor?
    A: See statement H. of Figure 6-6 "Other than the power supply pins, no pin should be driven before the 3.3-V rail has been fully powered up."

    Q: What other info might you need to help determine the cause of failure?
    A: Have you checked all of the other pins on the failed devices for shorts to VSS?

    Best Regards,
    Adam Dunhoft
  • I just got some new 'scope shots of VDD 3.3V rail vs 1.9V rail, and it is clear at these more accurate captures (faster timebase) that the 1.9V is ramping-ON BEFORE 3.3V rail reaches 2.5V.  Section 6.8 states the VDD must be > 2.5V before 1.9V ramps ON, and it is only at 3.3V.  Even though this does not seem it is sufficient for inducing a failure, I can see where a large current spike might occur with VDD < 2.5V and 1.9V ramping quickly ON.  Do you concur?

    ~Leonard 

  • It is dangerous to violate the power sequencing in this manner.  Is there any distortion in the lettering on the package or the surface of the package?  Does the device work with a correct power sequence?  The effects of violating the power sequence will vary die to die and this variation has to do with acceptable process variation.  It is not something we can characterize because it is destructive.  If the device is damaged, there is not much more we can do with it.  

  • I am told that once they develop this low-resistance on the power supply pins, they no longer will operate in a 'normal' manner, so we assume the IC has some destroyed silicon or oxide inside.
  • Apparently the 'scope captures previously submitted might not be correct.  If the power sequencing is indeed correct according to the datasheet, is there any other condition that could cause this type of VDDIO-VIDDA failure?

  • In my experience, the described problem is caused by a power event.  We have discussed power-up sequence.  Other possibilities: ESD during board manufacture or handling; latch-up, mechanical stress; over-voltage; overheating; negative voltage on power supply or input; come to mind.  

  • It has been a couple of weeks since the last activity.  If there is more to discuss, please respond.  If I don't hear back I will close this discussion 9/26/16.  

  • I believe this was resolved, and I'll verify with the end-user that is the case.

    ~Leonard