First of all, PSoC has a inner watchdog timer.
This function is act as well as external watchdog+reset.
Usually, the psoc having reset that do a initial process,
that clean all SRAM area and do initial process of hardware components(which you programed).
I think, you want keep state and information of components as same before, when that has reset. right?
I think, that is possible.
When first part of process you can check the cause of the reset.
If cause was watchdog reset, you could be skip initiate of hardware components.
Will it work so well?, I'm quite not sure however. please do it.
During a reset the chip is inoperable for a short time. This WILL affect your hardware logic.
After a "normal" reset (and after an internal watchdog reset, too) all the pins go into high-z. Then the internall logic gets re-configured from data in flash and the pins are set to their programmed state. This process will take some significant time.
On the other hand, a pure software reset could be done by setting the stack to a pre-defined value and loading the pc (program-counter) with the main() address (including some flag resets). This can be done in software.
So my suggestion would be to use an internal timer LIKE a watchdog that resets only the software leaving the hardwate untouched (as long as it is not proved inoperable).
Sounds not so good and match with observed at eval board, my hoping was that there is configuration possibility to get independence. Application is relative position measurement, working logic is essential while power is up. Thanks for your quick and useful help.
As long as you do not reset your PSoC your hardware logic WILL run. So the question arises how to make your software rainproof. There are methods for that, ie EVERY function returns, at least after a specified time or number of tries, reporting back success or failure. so no "hanging" will occur. "Deadlock" is a different situation where more than one independent processes try to acquire resources which are already in use by other processes. There are cures against that situation.
Software can be made error-free or at least made in a way that it is recognizing its own errors and handling them appropiately. So you should trust in the deterministic behaveour of todays processors as you already trust in the deterministic behaveour of programmable logic.
Bob, i'am with you at all! But unfortunately systems didn't build just out of controller and internal/external CPLD. In my bad world controller transceive lines from switches, actators and others, location of them is mainly based on mechanical constraints. This will result in high ESD risk, for some (e.g. industrial) applications your allowed to have a rebooting device if a ESD event occurs, of course without damage to the system and full restoration. If stand alone CPLD receive disturbance this will result in a much more "deterministic error" than a controller doing a reboot and kill the logic functions for milliseconds. Best regards.
The Watchdog does not power down system, so Verilog solution comes to mind.
The only issue I see is GPIO initialization on reboot (vs reset), are there any effects
produced by a Watchdog exception on restart. And could the Verilog solution
detect a Watchdog exception and reset its GPIO needed after a timeout of sorts.
You might file a case and ask staff -
"Create a Case"
Sorry for bring up this watchdog topic. Possibly better to name this reset regardless of reason. thank you and best regards.