An excerpt from the System Reference Guide:
The hardware implementation of the watchdog timer prevents any modification of the timer once it has been enabled. It also prevents the timer from being disabled once it has been enabled. This protects the watchdog timer from changes caused by errant code. As a result, only the first call to CyWdtStart() after reset will have any effect.
So it seems that only an enlonged interval might help you.
There is a dirty trick: usually you avoid serving the WDT with the help of an interrupt routine, but in this case you could use the GlobalSignal component and catch a CTW interrupt to clear the WDT. When your routine ends again you may disable that interrupt again to have the WDT cleares as usually.
In your watchdog function in main.c, where you enabled the timer, right click on the function and select "goto definition"
That should take you to the watchdog functions in "CyLib.c" In that source code, you can scroll up and down and find various functions, plus various explanations of what those functions do.
I suspect the function your are after is void CySysWdtDisable(void); Call that before you enter your library.
After you leave your library, pet the watchdog and then call void CySysWdtEnable(void);
I have not personally used the wdt, but this should get you on the right path of experimentation.
The WDT in the PSoC 4000 family is a simple 16-bit free-running up counter which can generate an interrupt only when the counter equals the match register value. The counter does not reset to “0” on a match, instead it keeps counting up to 0×FFFF and then wraps around to “0”. It runs from the 32 kHz internal low-speed oscillator (ILO) and cannot be stopped or disabled. The interrupt generation or causing the system reset can, however, be disabled. If enabled, the system reset feature of the WDT causes the system to reset on the third un-serviced WDT match event/interrupt.
CySysWdtDisable() is available only in the PSoC4, but the question was about PSoC5. There the WDT cannot be disabled (and thats the right way IMHO)
The code is enabled in the PSoC 5 library, so I assumed something incorrectly. The Creator datasheet on the WDT is very quiet about the API.
Then, the only way would be to extend the period, as Bob pointed out, or to pet it in an ISR, or to insert calls in the library code. If you have the source code to the library, you can pet it from inside the library.
In certain situations in the past, I have decompiled libraries into assembly, inserted calls, and re-included into the project. Very messy.
The KB article For PSoC 5 is at http://www.cypress.com/?id=4&rID=91775
If you need a temporarily disable-able WDT, looks like you will have to set up a timer and send output to a pin that is wired to your reset input. Crude but effective
From the TRM -
WRES - Watchdog Timer Reset
The watchdog reset detects when the software program is no
longer being executed correctly. To indicate to the watchdog
timer that it is running correctly, the program must periodically
reset the timer. If the timer is not reset before a user-specified
amount of time, then a reset is generated.
Note IPOR disables the watchdog function. The program must
enable the watchdog function at an appropriate point in the
code by setting a register bit. When this bit is set, it cannot be
cleared again except by an IPOR power on reset event.
Thank you for the replies,
I didn't well understand how to use IPOR for temporarily disable the Watchdog Timer.
Is there any function or any registry(I read something about PM_WDT_CFG, but it didn't work, but probably I did some mistake) that I call when I want to disable the Watchdog Timer and then I call the function CyWdtStart to re-enable it?
I use PSoC 5 and PSoC Creator 3.1 service pack 1.
Thanks a lot for your time.
IPOR = imprecise power-on reset
That means the WDT gets only disabled when the PSoC loses power. There is no other way.
You could always create your own WDT with a timer and use that
to reset chip with a register write if it is not periodically reset. Of
course the interrupt system would have to still be functioning, and
thats not guarenteed because a rogue process could disable the
interrupt system. So its not a perfect replacement for the WDT, just
You could also look at ARM debug system for M3, which include traps
and other exception handling.