Debug Recovery Mode
The debug recovery mode can be used to assist debug of external watchdog-triggered reset events.
It allows contents of the core L1 and L2 caches that were present before the reset to be observable after the reset. The contents of the caches are retained and are not altered on the transition back to the On mode.
By default, the core invalidates its caches when transitioning from OFF to an ON mode. If the P-Channel is initialized to the debug recovery mode, and the core is cycled through power-on reset along with system resets, then the cache invalidation is disabled. The cache contents are preserved when the core is transitioned to the On mode.
Debug recovery mode also supports preserving RAS state, in addition to the cache contents. In this case, a transition to the debug recovery mode is made from any of the current states. Once in debug recovery mode, a cluster-wide warm reset must be applied externally. The RAS and cache state are preserved when the core is transitioned to the On mode.
This mode is strictly for debug purposes. It must not be used for functional purposes, as correct operation of the caches is not guaranteed when entering this mode.
- This mode can occur at any time with no guarantee of the state of the core. A P-Channel request of this type is accepted immediately, therefore its effects on the core, cluster, or the wider system are unpredictable, and a wider system reset might be required. In particular, if there were outstanding memory system transactions at the time of the reset, then these may complete after the reset when the core is not expecting them and cause a system deadlock.
- If the system sends a snoop to the cluster during this mode, then depending on the cluster state, the snoop may get a response and disturb the contents of the caches, or it may not get a response and cause a system deadlock.