TM320VC33 Startup Issue

Hey Stuart
Unfortunately there is no one is apps with  knowledge of this old device, so I do not think we will be able to provide any device specific guidance or support on schematics/source code.
Assuming the issue is not systemic, and only % of boards fail and that too only a % of time, on an application/product that has been mass produced for a while, any debug will be a bit not trivial - ie. a simple code review/schematic review may not highlight the marginality.

I will ask internally if we can send the failing part for FA.

I will have standard questions that we should known the answer to
1) Has something changed in their design, software, board vendor that maybe causing the change.
2) Have they done any device swap to see if the failure follows the device or the board
3) Do see any temperature sensitivity , especially since you are talking external pull up potentially impacting behavior.
4) Does the documentation say whether or not TRST_N should have an external pull up?

Regards
Mukul

Please see the following additional information:

The issue appears to be happening on a large number of production boards, and in discussing with the manufacturing team, it seems to have been happening for some time.  The standard procedure has been to take the failing boards and remove the failing device with a brand new VC33 device.  This seems to make the vast majority of the failing boards all of a sudden work, leading me to believe something is very marginal within the tolerances of the manufacturing variation.  I will additionally ask the engineering team to take a device from a failing board and place it onto a known working board to see if the issue goes away.

This design has been in production for quite some time, but there have not been any significant changes in how the DSP is used in the design, however, there was some minor change in moving to a newer FPGA, but we are having a hard time understanding how this could be tied in with the failure since the only significant FPGA connection is the reset line.  I need to verify if the older FPGA design was having the same issue.

The failure is happening at normal room temperatures.  I'll ask the team if they can perform some temperature cycling of the board.

The datasheet states that the TRST_N line has an internal weak pull-down, but in noise sensitive designs, an external pull down of 1K to 50K is recommended.  We added 1K during our testing.

Thanks,

Stuart

Stuart

I forwarded this to a few folks and here is some additional feedback, which I believe is in line with the areas your customer is already looking more carefully

From your other posts ... 

  We also had a look at the RESET_N line with respect to power on.  The RESET_N line is held low for a full ~500 msec after the power supply is up and stable.  One thing we have noticed is that the external reset circuitry only holds the RESET_N line to a low level of ~400 mV.

This design has been in production for quite some time, but there have not been any significant changes in how the DSP is used in the design, however, there was some minor change in moving to a newer FPGA, but we are having a hard time understanding how this could be tied in with the failure since the only significant FPGA connection is the reset line.  I need to verify if the older FPGA design was having the same issue.

 The main change on the board was the FPGA, and the FPGA is driving potentially sub optimal RESET_N level, and you have only tried a stronger pull-down on the TRST_N line. Improving/replacing this RESET_N signal with a stronger signal should be another key area to focus (and compare/contrast with older working designs).

Mukul,

I want to note that the RESET_N only driving to ~400 mV is only on startup.  Once the FPGA is configured, it takes over the watchdog function, and actively driving the RESET all the way to ground whenever it times out.  Because the VC33 is locked up, the watchdog does timeout about once a second and drives the VC33 RESET_N line low, however this does not result in the VC33 starting up.

We are a little bit confused why the periodic active reset is not kicking the VC33 back to life.  The only hypothesis I can come up with is that the weak reset on startup is causing some latchup in the device, or somehow the device is stuck in a test or bootloader mode.

I also asked the following questions:

1. Does the boot-up issue ever happen on the older design before adding in the new FPGA’s?

1. As far as I can tell this is not a new issue, but the fall out is much, much higher than before.

• Have you tried taking a VC33 device from a failing board and putting it on a known working board to verify that the failure follows the device?  If not, could you please do so.

1. No, but we have replaced the DSP on a failing board and it started working.
1. Have you tried temperature cycling the board (cooler or warmer) to see if the failure incidence rate changes?

1. The original test that identified this issue, was running at 5 Deg C.  We change the test to 23 Deg C, and the rate of failure was the same.
1. Can you provide some details on the failure rates the manufacturing team is seeing on first inspection?

1. I will work on getting this for you.  I believe the last build had 6 DSP’s replace on 50 boards.  In testing we are seeing about 30% of the assembled board are failing to power on 50% of the time.

I iterated the importance of trying a bad VC33 device on a known good board, and have asked that this be tried out.

Thanks,

Stuart