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.

TMS320C6655: TMS320C6655

Part Number: TMS320C6655
Other Parts Discussed in Thread: UCD9222, UCD7242

Herewith some more information about this issue, as requested in the previous thread:

Using the feedback/questions from TI, I analyzed more in details what happen on a few “defective boards” and found the origin of the problem and a solution.

 

Explanation of the problem:

 

-          We know for a while that there are impedance variation on the C6655 DSP’s core power rails (CVDD and +1.0V). This impedance variation can be measured when the board is powered off and we can see a decrease by a factor of 2 or 3 when we compare a “good” and a “bad” board.

-          The symptom of the problem is an over-current flag from the DC/DC controller (IC16 – UCD9222).

-          I made a lot of measurements and see that:

  • The IC5 (UCD7242) over-current fault is not triggered
  • The current sense of IC5 is correctly sent to IC16
  • During the startup time of both power rails, there is an overcurrent during the ramp that occurs at about 0.2V-0.3V.
  • This inrush current has its peak value when the rail is about at 250mV and then decrease to the nominal current of the rail
  • Example data:
    • The +1.0V has a nominal current of 2A, but practically its current is about 1A.
    • On most board, the inrush current is limited to about 2.5A.
    • On some boards (the problematic ones), the inrush current can peak up to 3 to 4A.
    • The detection point of IC16 is at 3A. So any board with inrush current higher than 3A is automatically powered-down an cycle because IC16 power down the rail and the PLD sequencer restart the whole board.
  • The inrush current seams to decrease with temperature, so sometimes you can have a board that will restart all the time during 1 minute (because of our sequencer) and then stabilizes in a functional state
  • On the attached screenshot (TEK00011.PNG), you can see:
    • In yellow, the rail voltage that starts ramping
    • In blue, an image of the rail current with 1A = 444mV
    • Peak inrush current occurs at 250mV
    • DC/DC is stopping because the current goes too high from the threshold (threshold at 3A = 1.32V)
  • On the attached screenshot (TEK00012.PNG), you can see the same situation where the inrush current is a bit lower, so the voltage ramps up to the good value

 

Solution to this problem

 

-          I made a lot of investigation on the DC/DC controller IC16 (fully programmable digital chip). Basically I re-used the programming files from TI reference design since this part of the power supply was almost a copy/paste of their design. Since we have issues, I decided to go deeper in the parameters and check if the reference design was good or not. Basically I made some differences in the programming files to be sure it reflects 100% of our own design, but it didn’t change anything to the described behavior.

-          The whole design is very protected against overcurrents : PTC fuse at the input, overcurrent/thermal protection inside power chip IC5 and current monitor in the controller IC16. So I decided to change the detection threshold inside IC16 (moving them from 150% to 220% of nominal current). It was better, but sometimes some boards had inrush currents larger than the new threshold.

-          The final update I made was the good one : having the power rails rising faster. The inrush current is only present at specific very low voltages during ramp up. The original design had ramp up time of about 4ms, which is not very fast for such a DC/DC. Since nothing in the DSP’s datasheet restricts the minimum rise time (only restriction is to have both rails up in less than 100ms), I decided to lower the rise time to 1ms (which is the value used for others DC/DCs on the board and the result is positive: As the “bad zone” near 250mV is crossed faster, the inrush current is lowered. You can see the result on attached screenshot TEK00017.PNG

tek00011.png

tek00012.png

tek00017.png

  • Hi Johan,

    Thanks for sharing this useful information. I am sure this will be greatly appreciated by the people dealing with similar problems in the e2e community.

    Best Regards,
    Yordan
  • Hello Yordan,

    This was more a question than a resolution from my side.

    Customer asked me to check with you guys if this solution is appropriate for the issue they had. He would like to be sure that they don’t have a requirement which I don’t know  for the ramp-up time of the DSP’s core

    Regards

    Johan

  • Hi Johan,

    I've notified the design team to elaborate.

    Best Regards,
    Yordan

  • Johan,

    I understand your problem description, observations and conclusions.  All seem reasonable and the solution robust.

    Please clarify the supply rail that has the inrush current.  You refer to it as the +1V supply.  Is this the CVDD1 supply source?  Does it also connect to the VDDT1 and VDDT2 supply pins?  Does it connect to anything else on the board?  The Errata contains the Usage Note 10 which discusses leakage from the VDDT supply into the VDDR supply.  Does the overcurrent condition align with the timing of the leakage into the VDDR circuitry?

    You said in your first post that this was detected in production.  What percentage of boards fail in this manner?  Have you seen any field failures after boards have already been installed by a customer or are these only production line failures?

    Tom

  • Hello Tom,

    herewith the answers on your questions:

    Q1: 

    the problem occurs on one of the two rails: either on our DSP-CVDD rail (connected to DSP CVDD) or on our +1.0V-DSPCORE rail (connected directly to DSP CVDD1 and connected through EMI filters to DSP VDDT1 and VDDT2, just exactly the same way as on the reference design). VDDR is connected to another DC/DC generating +1.5V rail. VDDR is enabled 8ms after VDDT by our sequencer. I don’t know if it’s related to this Usage Note 10 since the issue occurs after less than 2ms from the powering of VDDT (see screenshots of my previous message) and at this time VDDR is still OFF. The Usage Note doesn’t give metrics about the amount of leakage current. But this 1.5V rail is supplying all the DDR part of the DSP and also the DDR part of another CPU on the board, so maybe it could be a root cause. But anyway there are variations amongst all manufactured boards and that’s the main point of our problem.

    Q2: we have between 1% and 3% of failed board, depending of the production batches (total production at this time is about 4000 pieces). We never had the issue in the field

    Johan

  • Johan,

    Thanks for the additional detail.  I believe that you have a reasonable and robust solution to the problem seen on your board - and it should be applicable to all boards produced in the future.  Please let me know if you have any further questions.

    Tom