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.

TMS320F28032: Abnormal states for TMS320F28032

Part Number: TMS320F28032


Hi Team,

  My customer reported an TMS320F28032 abnormal state while in their power module output shorten/100% load switch test:  the TMS320F28032 worked abnormal with unexpected CLKOUT frequency and with XRS in high state.

  Could you kindly help on below items:

1)       From the test procedure, the abnormal state is not recorded like LIMP/STANDBY/HALT/IDLE mode, could BU side give comments for the CPU states and how to identify the CPU states?

2)       According to customer’s feedback, the abnormal seems happened while the VDDIO with larger ripper and external OSC, any comments for the reasons of the abnormal? Should higher the VDDIO and add more capacitors for VDDIO filter?

Expect for your reply, thanks.

Background:

  1. The TMS320F28032 worked as DCDC controller(rectifier application) and located in secondary side.

  2. The test waveform and test condition shown as attached.

TMS320F28032 Clkout frequency abnormal.docx

  • Benjamin,

    There is quite a bit of information in here.  Can you clarify these points:

    • Am I correct in understanding that the device does not enter the fail mode if the internal zero-pin oscillator is used for the clock source?
    • What is the external clock source?  Is it a crystal/resonator on X1/X2 or is it a digital oscillator on CLKIN?
    • Does the device ever recover normal functionality after the 50A short is removed?
    • Are they able to connect to the device through JTAG the 50A is removed?  If so, is the PC at a normal location?  What are the values of PLLCR, PLLSTS, NMIFLG, and WDCR?
    • Can the device recover with a manual XRSn reset or does it require a full power-off and power-on sequence?

    I suspect that the 50A short is disturbing the external clock input circuitry.  You can try these experiments to continue debug:

    • Configure a spare GPIO pin to output static high.  Monitor VDDIO, the spare GPIO, and the external clock at the device input pin during the 50A short.
    • Using the external clock, configure the PLL to bypass mode and XCLKOUT = SYSCLK.  Does the device fail during the 50A short in PLL bypass mode?  How does XCLKOUT look during the 50A short?

    -Tommy

  • Hi Tommy,
    . Yes, this issue didn't report with internal zero-pin oscillator for the clock source until recently.
    . Crystal/Resonator on X1/X2.
    . The device could not recover to normal after it happened.
    . Has required customer to tried with JTAG, but due to the system limitation, the JTAG emulator has broken for 3 times even with isolated operation; so it's hard to via F28032 with JTAG;
    . The device can be recovered with a full power-off/on sequence, and also can be recovered with manual XRSn reset;

    During the test, customer configured XCLKOUT = SYSCLK for test, but the PLL is not bypassed, and for the external Crystal input pin can not be monitored as with the probe the F28032 can't work. Also for the test, now is working with customer for further test.

    From your feedback, do you have some concerns for PLL be affected via the external Crystal circuit? noticed that during the test, the voltage of VDDIO(3.3V) will be affected, which may make the F28032 get into limp mode. For limp mode, my understanding is that the F28032 will be kept as limp mode but without reset until manual reset on XRS or power-on/off sequence, which is confused customer what kind of mode would be entered for the F28032 CPU state, could you kindly give comments?

    Expect for your reply, thanks.

    Best Regards
    Benjamin
  • Benjamin,

    It is difficult to say what may be happening without further experimentation. From the observations, it sounds like the clock on X1/X2 is being disturbed. However, it is not clear how this disturbance is causing the device to fail. Bypassing the PLL and monitoring XCLKOUT will let you see what the input clock looks like from the system perspective.

    Is it possible to keep the emulator physically disconnected until after the 50A short is removed and then connect through JTAG? This would tell you exactly what state the device is in (when in the fail mode) without subjecting the emulator to undue stress. From the original observations, I would not surprised if it is in LIMP mode. However, I interpreted your statement that "From the test procedure, the abnormal state is not recorded like LIMP/STANDBY/HALT/IDLE mode" to likely mean that the PLLSTS register did not have MCLKSTS set.

    -Tommy