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.

TMS320F28069: TMS320F28069

Part Number: TMS320F28069

Hi All,

I am facing a very different issue in TMS320F28069. Controller is getting reset(XRS interrupt) after certain power electronics components are added. So how can read or understand the root cause of this reset? As it is not expected as per the circuit,

Thanks all in advance!!!

  • Prashant,

                You are facing an EMC issue. Likely, your board is getting reset due to noise. 

    ESD/EMI events are capable of inducing all sorts of bizarre behavior in the device, including random resets. The solution lies in hardening the circuit design to make it immune to the disturbance. The challenge lies in determining precisely how the disturbance impacts the circuit. i.e. in identifying exactly how noise couples into the circuit. In other words, what is the conduit for this noise to get into the circuit and cause the malfunction? Once this is identified, it is relatively easy to come up with the protection solution. Unfortunately, often times, the shortcomings are discovered after the board is made and hence make the redesign of the board necessary. 

    Many books have been written on this topic and many papers published. The actual circuit design, the components used, the geometry of the components, the board layout, the board stack-up, the shielding employed , all play a role in the immunity strength of the design. Debugging such problems is an iterative process and warrant hands-on debug. It is extremely difficult to debug issues like this remotely, without access to the schematics, PCB layout and the hardware itself. In other words, remote debug is not practical. The first task is to find whether the noise is coupled conductively or radiatively into the system. i.e. whether the issue at hand is one of conducted immunity or radiated immunity. Once this is identified, we need to identify the entry point of the noise into the system. Only then can we come with a solution. Problem could be related to insufficient decoupling/filtering, incorrect layout, improper (or lack of) shielding etc. There are numerous resources online that deal with this. Hard to explain them in a post. Please google "EMC shielding" for helpful links. 

    A chattering relay is helpful in generating noise across a wide spectrum. It is an extremely simple circuit. Since it is not electrically connected to the circuit, it provides a simple way to ascertain if the circuit is affected by radiated noise. 

    Specifically for the reset issue, ensure that the -XRS pin is driven by device with an open-drain output and that a strong external pull-up is used.

  • Thanks Hareesh for quick fast.

    It looks that it not the issue of noise as it is already tested board for many years but will surely look into your perspective. Can you tell me is there any SFR which is updated when XRS interrupt is generated by which I can reach the cause of it?

  • Prashant,

                As mentioned in my previous post, remote debug of such issues is not feasible. However, I can offer some suggestions. If this is a design that has been working for “many years”, noise may not be the cause but still cannot be ruled out completely. XRS is not an “interrupt” in the sense that word is used generally. I don’t understand what you mean by "SFR which is updated when XRS interrupt is generated ". If you are asking about any register where the reset cause is stored, the WDCR register can be used to determine if the reset was initiated by the WD. 

    Please answer the following questions: 

    1. How long has this design been in production?
    2. How many boards have been shipped with this device till date?
    3. In how many boards is this problem seen? What is the DPPM value?
    4. In a board where the problem is seen, is the problem intermittent or permanent?
    5. If the problem is intermittent, how often is it seen?
    6. Is it possible to reproduce the problem easily and consistently?
    7. Is this seen in a device that has been working fine for some time? If so, how long?
    8. What is the exact nature of failure?
    9. Is it possible to reproduce the problem with CCS-JTAG connected?
    10. Is the - XRS pin being driven by a open-drain device?
    11. Is the Watchdog enabled?
    12. If the issue is EMI related, does changing the following affect the behavior: (1) Lowering the power of the power-stage (2) Running a simple GPIO-toggling code instead of the application (3) Lowering the value of the resistor on the -XRS PU and -TRST PD.
    13. Does the design provide adequate decoupling capacitors as stated in the datasheet?
    14. Assuming an external clock is used, is the problem seen if the system is run with INTOSC1/2?
    15. Would you be willing to share the schematics with us privately?