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: reset --> uC hanging what about PWMs status

Part Number: TMS320F28069
Other Parts Discussed in Thread: TPS3825

Hello everybody ,

I m on a F28069 @ 90MHz , ext quartz 20 MHz .   I have already some thousands of units produced in the field , where I found some issues  when a Reset by Watchdog is fired : many times uC  does not restart and I can see a Train of pulse on the reset pin ( up to some tens ) before it starts back .

We understood  HW on reset pin is not 100%  correct ( we have reset pin  with a 10nF to GND and straight connected to an external supervisor TPS3825 , no pullup  ) and we ll fix for future production  , but as for now we have units in the field and we need to understand and confirm what is happening now . 

so as for now on the board I can see  reset pin  going down to about 1.62V   , mS large of pulse is far more than the 512 clock cycle needed , but  as said I see  a train of reset pulse before the uC starts back ( in attach a scope image  Green – XRS togglingYellow – HIGH a the beginning of main, TOGGLING during while(1) for watchdog reset)  ) 

so questions:

1- why uC is not restarting ?  Is it due to  reset voltage level ?

2- what about PWMs statuw when  CPU does not restart ?    I can see them at low level stuck ,  but this is due  or by chance ?    I need them to stay  grounded  in this situation when CPU not executing

3- if I push watchdog to 500mS  , then I only need  3-4  reset before  CPU restarts executing ( instead of a very long train o pulse )  : why ? 

any suggestion on what should I do ?

thank you very much

regards

Carlo

  • Carlo,

    Colombo Carlo said:

    1- why uC is not restarting ?  Is it due to  reset voltage level ?

    for above, I will ask some one from analog team to look at this question as it involves understanding of ,if MCU is brought out of reset before VDD is set to the needed threshold.

    Colombo Carlo said:

    2- what about PWMs statuw when  CPU does not restart ?    I can see them at low level stuck ,  but this is due  or by chance ?    I need them to stay  grounded  in this situation when CPU not executing

    All the IOs are inputs by default at reset. So no PWM signals are active unless application re configures them and enables PWM peripheral.

    Colombo Carlo said:

    3- if I push watchdog to 500mS  , then I only need  3-4  reset before  CPU restarts executing ( instead of a very long train o pulse )  : why ? 

    Again here, I'm not sure why you are seeing such a long train of pulse. After a WDOG reset is issued and the MCU has enough supply voltage by the time reset is released, you should not see this train of pulse. Did you try to scope VDD to see if you are seeing these resets before VDD is at the threshold?

    Best Regards

    Santosh Athuru

  • Carlo,
    can you also confirm if user is setting the boot mode pins to boot to flash and have the boot mode IOs in the scope as well. Multiple back to back resets after a watchDOG reset doesn't make sense unless the boot mode pins are not set to flash boot properly after a watchdog reset or unless the VDD supply is not stable. The device eventually booting to flash after a train of resets indicates problem with supply, but scope out the boot mode GPIO as well to confirm.

    Best Regards
    Santosh Athuru
  • Carlo,

    I doubt that we will be able to provide you with a full explanation of the observed behavior when the XRSn signal is not handled properly. The XRSn pin uses an open-drain buffer and is meant to operate with other open-drain signals. The push-pull buffer for RESETn on TPS382x will introduce contention on XRSn when the F28069 watchdog tries to pull the XRSn signal low while RESETn is actively driving high. This is evident when the XRSn signal is only able to reach 1.62V, which is not low enough to satisfy the maximum VIL level of 0.8V. It is likely that the voltage sensed by XRSn inside of the package is lower than the externally visible 1.62V, but there is no way of knowing the actual voltage.

    Further, the XRSn signal has a requirement of needing to stay low for at least 32 clock cycles. This can be thought of as a synchronous reset where various state machines on the device transition to the reset state within 32 clock cycles rather than as an asynchronous reset where only a minimum time must be met. It is very possible that the device may be experiencing partial resets if XRSn VIL is met for less than 32 cycles. In such a scenario, some portions of the device may be able to reset while others are not. XRSn state changes during the 32 cycles can further complicate things.

    Ideally, the RESETn to XRSn signal should be replaced by one that uses an open-drain buffer. If this is not possible, the current limiting resistor should be placed between RESETn and XRSn rather than between VDDIO and XRSn.

    -Tommy