We are utilizing the Zynq 7k's System Watchdog Timer in our design. We have configured the watchdog to use the internal cpu clk and to reset the processor on timeout.
About half of the time we kill the task petting the watchdog, the cpus still continue to run. In this case, we check the SWDT status register and it is 1 indicating a timeout. We also double-check the control and configuration registers to make they are still set appropriately, which they are. The other half of the time when the SWDT seems to do something, the cpu just hangs instead of resetting back into the FSBL (we have prints turned on in the FSBL). This is similar to behavior we have seen before when encountering a secure lockdown by the bootrom. This behavior occurs in secure boot mode, as well as unsecure boot mode.
The TRM and SecureBoot documents both indicate that the suggested way for the SWDT to reset is to configure it for interrupt and have the handler assert a gpio pin to an external CPLD which then asserts the POR_B signal. However, it does not say this is necessary, and further does not confirm that the SWDT interrupt should successfully execute in all cases (it seems possible the cpu could get so far off into the weeds that this interrupt itself doesn't execute). The TRM also indicates that MIO pins 15,27,39,51, 53, or EMIOWDTRSTO can be tied to the SWDT reset out signal for asserting POR_B in the same way. However, this brings up the concern of a race condition between the actual reset and the POR assertion.
Could anyone clarify:
Does the SWDT reset work in the secureboot case without adding extra logic for POR?
Is the SWDT interrupt guaranteed?
If using one of the GPIO pins that can be tied to the SWDT reset out, how can we avoid a race condition between that and POR?
Any idea why the SWDT only kicks half of the time it times out?
I can provide more details on our configuration if need be.