• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 277 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.

CCSTUDIO: Watchdog Timer Sometimes Does Not Reset Device

Ed Sanders
Genius 4125 points

Part Number: CCSTUDIO
Other Parts Discussed in Thread: TMS320F28388S, C2000WARE

Greetings,

We are using the TMS320F28388S.  We have a process where we deliberately create a watchdog timeout.  I am seeing that sometimes it will occur and sometimes it won't.  Just prior to waiting for the timer to reset the unit, we initialize it and set it up.  The initialization and setup use constants only so there is no variability from one use to the next.  Is there some other setup which needs to occur to make it happen?

Thank you,

Ed

  • 0
    Genius 4125 points

    Some additional information...

    At the point where I can see the issue, the SCSR register has a value of 0x0005 which shows that there is no watchdog signal and that it is configured to cause a reset.  But when I refresh the registers, I can see WDCNTR changing.  The processor is at an instruction which jumps to itself - an infinite loop which is waiting for the WD reset to occur.  Also, this module takes no interrupts, and interrupts are disabled.  So an interrupt cannot be restarting the timer.  And IER is 0.

    Thank you,

    Ed

  • 0 in reply to Ed Sanders
    TI__Genius 16376 points

    Hi,

    I would advise to start with the Watchdog C2000Ware example and see if you are able to make that trigger device reset.

    Thanks

  • 0 in reply to Prarthan Bhatt
    Genius 4125 points

    Hi Prarthan,

                    This is code which has been working for years using both the 379 and 388 DSPs.  Now, we are developing a new product, based on the 388, with a different communication interface.  It is this new product which is failing.  It is running on the same hardware as another product which is successfully using the watchdog.  So the change is the communications.  But I don’t see how that change could cause this.  And comparing the setup of the watchdog with the version which works, they are identical.

                    Another data point.  If I force the reset by writing a value of 0 to WDCR, it will occur.

                    Also, when the reset does not occur, I can see that the timer is running.  It simply doesn’t generate the reset at the roll over.  And I’ve checked to ensure that the rollover does occur, and it does.

    Thank you,

    Ed

  • +1 in reply to Ed Sanders
    TI__Genius 16376 points

    Hi Ed,

    Could you check if there are back to back writes to any of the below registers that are not following the given criteria.

    If the below delay is not accounted for then please try after adding that delay.

    Thanks

  • 0 in reply to Prarthan Bhatt
    Genius 4125 points

    Hi Prarthan,

                    That was it!!!  Looking at the generated assembly, the time between the two writes was a little bit less than the amount required by the formula.  I added the appropriate delay after the first write, and it worked immediately.

    Thank you for making me aware of that.  It would be helpful if, in the Watchdog and other appropriate sections, there was a reference to section 3.14.

    Thank you again for your help,

    Ed

  • 0 in reply to Ed Sanders
    TI__Genius 16376 points

    Ed,

    If you are using latest driverlib functions we added this delay in the appropriate Driverlib API itself.

    But it is also know that several users do bitfield programming or create their own API's in which case its very likely to hit this bottleneck especially in a highly optimized code can create back to back write with these registers.

    Thanks

  • 0 in reply to Prarthan Bhatt
    Genius 4125 points

    OK.  Thank you Prarthan.

    Ed