TMS320F28377S-Q1: The DSP chip occasionally fails

Hi Tang,

A few points to check for based on previous device discussions.

1. Crystal oscillator circuit design flaw A 1MΩ parallel feedback resistor across the external crystal (X1/X2) is a discouraged design practice that causes oscillator instability, leading to repeated resets/failures to run after a period of field operation (one case: 26 of 108 field units affected, resets appearing after ~1 year of otherwise normal use) 1. Removing this resistor is the standard recommendation, though in that case removal introduced other power-off abnormalities — indicating the full oscillator circuit (crystal, load caps, feedback resistor) needs review together.

2. Faulty/marginal external crystal hardware A hardware defect in the external crystal circuit allowed initial boot on the internal oscillator (factory default) to succeed, but once firmware configured the device to switch to the external crystal, the MCU failed to run on subsequent power cycles — appearing as "device failure" but rooted in the crystal circuit, not the DSP die 2.

3. Electrical overstress (EOS) on GPIOs / internal core rail short Sporadic internal shorts on the core voltage rail (and separately, GPIO banks stuck at 1.2V) were observed after 20–50 hours of run time in ~8% of boards. The rail itself measured clean/stable, but significant switching noise (e.g., motor-induced) was present on signal lines (I2C SDA/SCL) into the device — pointing to overstress conducted through GPIO protection diodes as the suspected mechanism, rather than a rail supply issue 3.

4. Startup-code-triggered system fault masking as a hardware/debug failure In one case, the debugger connected fine at boot-ROM, but disconnected immediately upon code execution (Error -2062, unable to halt device) — consistent with a bad clock configuration, unserviced watchdog, or power supply issue on the custom board that only manifests once the CPU becomes active 4.

5. General semiconductor reliability mechanisms (background context, not case-specific) For any digital IC with embedded SRAM/flash, intermittent failures can also stem from: latent manufacturing defects not caught by production test margining, circuit performance drift with usage/time, or circuit overstress (voltage/temperature outside datasheet limits) 5. These are generic failure modes, not specific evidence from your U40 case.

Recommended Next Steps for the U40 Failure Analysis

In each case TI support requested the same diagnostic evidence. To narrow down your U40 cause, gather:

• Full schematic of the crystal oscillator circuit (check for any parallel resistor, load cap values) around U40 1
• Oscilloscope capture of the reset/power event when the failure-to-start occurs (VDD, VDDIO, XRSn, and crystal pins)
• Confirmation of decoupling capacitors and GPIO protection diodes per the datasheet and the TIDA-00392 reference design 3
• Whether watchdog is enabled and whether disabling it changes the failure behavior 1
• RESC (reset cause) register and NMISHDFLG register readout from the failed U40 units, if recoverable 2

Follow up: Can you share the U40 crystal oscillator schematic and a scope capture of VDD/XRSn during a failed start-up event, so the root cause can be narrowed to oscillator design, EOS, or power sequencing?

1. TMS320F28377S-Q1: The issue of powering on and resetting the chip
2. TMS320F28377S-Q1: Load Fail in CCS / Uniflash
3. TMS320F28377S-Q1: core rail shorts to ground inside chip
4. TMS320F28377S-Q1: TMS320F28377S programming issue
5. Sources of SRAM Failures Application Note

Best Regards,

Zackary Fleenor