• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 276 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMS320F28062F: Noise test of TMS320F28062FPZT

Conor
Guru 15090 points

Part Number: TMS320F28062F

Hi,

When a malfunction occurs in a noise test, the MCU cannot be reset even if the reset pin of the MCU is set to low level from the outside in order to recover from it.

If it is normal (before it malfunctions due to noise), it can be restarted by resetting the reset pin to low level.

In the unlikely event that the MCU malfunctions, it is necessary to take countermeasures against the state in which it can only be restored by turning the power on again.
Could you please give me some advice on how to do this?

Thanks,

Astro

  • 0
    TI__Guru* 85910 points

    Astro,

    If the C2000 can only be recovered by a power cycle and not a XRSn event then I think that we have potentially latched up the device into a bad state.  This would be caused by an over-voltage event on one or more C2000 device pins.  Do you believe/or have captured that the noise is coupling to the C2000 in such a manner to drive a pin to VDDIO +0.7V or greater?

    Another alternative is that the noise has coupled to the JTAG pins and caused the device to enter boundary scan mode.  I would think that XRSn should recover this condition, but would need to check.  Can you monitor the JTAG pins in your system and note if they are seeing excess noise?  The remedy here would be to increase the PD strength on TRSTn.

    Can you comment on how the device behaves once the noise event happens?  Does it appear "dead" or is there some pin activity?

    Best,

    Matthew

  • 0 in reply to MatthewPate
    Guru 15090 points

    Hi, Matthew

    Thanks for the comment. As you said, I understand that there is an effect due to latch-up or JTAG noise.
    For noise countermeasures, I would like to do it separately.
    If the phenomenon that cannot be reset this time occurs, it is necessary to take countermeasures against the state that can only be recovered by turning the power on again. If there is any way to deal with it, I would like some advice.

    Thanks,

    Astro

  • 0 in reply to Conor
    TI__Guru* 85910 points

    Astro,

    If we have latched the device I am more concerned with this from a device reliability standpoint since it means there was either an over/under voltage event on the pins, or a supply rail that went missing during run time. 

    Do you have any observations with a scope/DMM if this is happening in your system vs just coupled noise?

    For noise effects, we can look to increase the decap on the power rails as well as increase the strength of the pull resistors on the JTAG pins.  It is also important that both decap and pull resistors be placed as close as possible to the device pin to get the max effect/benefit.  If the passive is far away physically on the board then noise can couple on the trace of the pin/signal.

    I would like to re-emphasize, however, that if you have a device that cannot be recovered with XRSn toggle this is not due to some noise on JTAG.  There are also ESD shield material we can look to apply to the device area mechanically, but I think if we have latched the device we are not dealing with a coupling issue, but an event on the signal/pin itself.

    Let me know if the above makes sense.  Bottom line is that we need to identify the root cause/source for this over/undervoltage event to better understand how to mitigate it.

    Best,

    Matthew