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: XRS pin condition at BOR reset

Part Number: TMS320F28032

What happens to XRS pin during BOR reset condition?

In normally if WD reset occurs this pin held low for 512 OSCCLK and WDFlag is set.

If BOR reset occurs what time XRS pin is held low and WD flag is still set or not?

Thanks,

  • In our application XRS pin is pulled low for a duration 57us at run time not at power up time and after XRS is released WD flag is set.

    We checked VDD 3.3V supply of micro and some glitches or noise appears on supply voltage. But its stable even at reset condition.

    Can we sure that this condition is WD reset it not BOR reset?

  • I should add one more point about this issue that if BOR is disabled using BORCFG register we didint see any reset condition.

    I can summarize the condition 

    if BOR and WD reset enabled, at run time XRS pin is pulled low for 57uS and WDFlag is set after that.

    if BOR is disabled using BORCFG and WD is enabled reset condition is not seen.

    What can be the reason of reset? Is it BOR or WD?

  • In our application XRS pin is pulled low for a duration 57us at run time not at power up time and after XRS is released WD flag is set.

    WD reset is active for 512 OSCCLK cycles. If INTOSC1 is used as the clock source, width of WD initiated reset would be approximately 51.2 us. 57 us is a bit too long but unless I see the scope waveform, it is hard to tell. 

    We checked VDD 3.3V supply of micro and some glitches or noise appears on supply voltage. But its stable even at reset condition.

    Some ringing on the supply rail is inevitable but the question is of the magnitude. 

    Can we sure that this condition is WD reset it not BOR reset?

    If the pulse width is about 512 OSCCLK cycles, it is definitely from the WD. I am assuming the clock source for the MCU is INTOSC1.

    BOR and WD are independent of each other. One doesn't impact the behavior of another. The symptoms you are presenting are contradictory. On the one hand, it appears to be a WD initiated reset. OTOH, it appears to be a BOR. I want to bring your attention to an important parameter in the datasheet: 

    Supervisor reset release delay time (Time after BOR/POR/OVR event is removed to XRS release) MIN = 400 uS, MAX =  800 uS.

    A BOR initiated reset should last much longer than 57 us. 

    The correct behavior of WDFLAG is dependent on the total capacitance seen at the -XRS pin. Following would be useful to know:

    1. What is the magnitude of the maximum peak-to-peak ripple on the VDDIO pin? Attach scope capture.
    2. What is the total capacitance at -XRS pin? Please attach the schematics for the reset circuitry. You can send the schematics privately to me by initiating a friendship request.
    3. I need the scope capture of the active reset waveform.
  • Hi Hareesh,

    INTOSC1 (10Mhz) clock is used.

    XRS is connected to 3V3 supply only with 2k2 pull-up resistor. No caps is connected to XRS pin.

    XRS pull-down time is 57.2uS as seen at picture shown below. Picture is captured at run time.

    So what can be the reason for reset WD or BOR?

  • At the scope view 

    Blue is XRS pin and

    Pink is 3V3 micro supply

  • Rasit,

              As mentioned before, the symptoms you are presenting are contradictory. The width of the reset pulse seems to point to the Watchdog, but you also say that the reset issue goes away when BOR is disabled. Note that width of WD initiated should be exactly 512 OSCCLK cycles, so if INTOSC1 is oscillating at 10 MHz, the width should be 51.2 us, not 57.2 us. This makes me think if WD may not be the source. 

    1. Are you using the on-chip VREG? If so, can you please check if your board has the required decoupling capacitors for the Vdd pins (see datasheet for the required value). 
    2. Can you provide a scope capture of the ringing on VDDIO and VDD pins? Please use AC coupling and switch to “X” cursor mode and let the scope measure the peak-to-peak value accurately. 
    3. Is the issue seen with your application running? If so, could you please try this experiment: Do not enable the clock to any peripheral. Simply run a while(1){} loop with the clock frequency of the device = 10 MHz. 

    Please share the schematics of your design with me offline. You can do this by initiating a Friendship request with me.

  • I will will sent the data but I want to know that

    Other than WD or BOR any condition can cause reset during runtime with a duration of 57uS?

    As an example clock fail, 1.8V Vreg out voltage, code crash ...

     And if this WD reset and XRS time 57.2uS than INTOSC1 becomes 11.1Mhz. Is it possible?

  • Following are the various types of reset:

    • POR
    • BOR
    • -XRS pin (warm reset)
    • WD (code crash) -
    • MCD (Missing Clock Detect – Loss of input clock) – This is highly unlikely since you are using INTOSC1.
    •  In addition to the above, a ESD/EMI event can also reset the device.

    Please provide the answer/information for my 3 questions in my previous post. In addition to those, please answer the below questions as well. While going through each question in the debug checklist below, evaluate whether it could be the cause of what you are seeing.

    1. How long has this design been in production? Or is it yet to go into production?
    2. If this design is in production, 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. Does the code work fine with the JTAG connector connected? If so, are there any initialized constants in RAM?
    10. Is it possible to reproduce the problem with CCS-JTAG connected?
    11. Does it make a difference to run the code from Flash as opposed to RAM?
    12. Are the wait-states correctly configured for the Flash per our datasheet recommendations?
    13. Are the levels of the boot-mode pins correct while the device is coming out of reset (and when the boot-ROM takes a snapshot of those pins)?
    14. Are there any pins that are driven before the device is fully powered up? i.e. the rails have reached their final steady-state value?
    15. Assuming it is practical/feasible to run the application in a TI-designed board like ControlCARD/LaunchPad, is the problem seen in those boards?
    16. If the device has a - TRST pin, is there a pull-down of 2.2k or less?
    17. Is the - XRS pin being driven by a open-drain device?
    18. If the device locks up due to a EMI/ESD event, is the watchdog able to pull the device out of this condition or is a power-cycle warranted?
    19. How do you handle a missing clock condition in your code?