Reset Cause

This MotoHawk™ block allows the model to query the module for the cause of the last reset.

Block ID

Reset Cause

Library

MotoHawk_lib/Extra Development

Description

Overview

This MotoHawk™ block allows the model to query the module for the cause of the last reset.

The feature may not be supported, in which case a response of Unsupported will be returned.

This block can be used to distinguish a cold power up from a warm power up by examining this result. Values above 2 are associated with unexpected resets. The implementation can decide whether User Initiated represents a cold or warm power up. The MotoHawk status variable "System | Status | PowerUpStatus" considers all causes of a reset besides Power Up to be a warm reset.

Multiple instances of this block may exist in a model, but the value reported is captured on start-up by MotoHawk and this block just reports this cached value.

The motohawk_resetcause_enum M-script enumerates the possible responses.

Signals

Reset Cause (uint8, enum)

The cause of reset.

Reset Cause Unsupported (value=0)

The feature may not have been implemented on the core or the hardware is not capable of distinguishing the cause of a reset.

Power Up Reset (value=1)

The module reset was caused by a power-up from a low voltage.

User Initiated Reset (value=2)

The user can initiate a reset using the Force Module Reset block. Some systems may force a reset of the system too, for example when programming.

Loss of Clock (value=3)

Some modules are configured to reset if the main microcontroller detects that its primary oscillator has stopped.

Loss of Lock (value=4)

Some modules are configured to reset if the main microcontroller detects that its primary phase lock loop (PLL) oscillator has lost lock. Timing of events is impacted if the oscillator loses lock.

Watchdog Reset of Unknown Cause (value=5)

Most modules support a CPU operating properly (COP) watchdog mechanism. The watchdog must be serviced appropriately or it will force the CPU to reset on the assumption that it is not operating correctly. In this case the exact reason why the CPU was not considered to be operating correctly is not known. A common cause of this failure is to permanently disable system interrupts.

Watchdog Reset due to Critical Section (value=6)

The watchdog identified that a critical section was entered, but that did not end. This can compromise task execution and should not occur. The module was therefore reset.

Watchdog Reset due to ECC Memory Failure (value=7)

Some microcontrollers support hardware that execute ECC memory checks on the Flash and/or RAM. A watchdog reset was issued because this system observed a memory failure.

Watchdog Reset due to Unhandled Interrupt (value=8)

The watchdog observed the execution of an interrupt that was not handled (nor expected) and so the module was reset.

Watchdog Reset due to Task Starvation (value=9)

The CPU operating properly (COP) watchdog monitors task execution. Task starvation is said to occur if the kernel's idle task is unable to execute within the starvation time defined by the Starvation Timer block. The kernel's idle task only executes when there is nothing else that needs to execute. If it is starved then CPU utilization is too high. The most likely cause of such starvation (assuming CPU utilization is normally within bounds) occurs because a tasking thread of execution has become stuck in an endless loop (or equivalent).

Watchdog Reset due to Task Stack Overrun (value=10)

Each task has a stack that is used to store local variable and its execution context. The CPU operating properly (COP) watchdog monitors each of the executing tasks. An overrun task stack implies memory corruption, which means the kernel's execution is no longer deterministic and so the watchdog forces the module to reset.

Watchdog Reset due to Interrupt Stack Overrun (value=11)

There is an interrupt stack that is used to store local variables and interrupt execution contexts. The CPU operating properly (COP) watchdog monitors this stack. An overrun interrupt stack implies memory corruption, which means the kernel's execution is no longer deterministic and so the watchdog forces the module to reset. Interrupts can often nest (occur on top of each other). This makes greater use of the stack and may require the interrupt stack to be sized larger than would be needed to support just a single interrupt. It is recommended that spare RAM is allocated to the interrupt stack to give this stack more margin and allow it to better deal with nesting.

Watchdog Reset due to Processor Exception (value=12)

The CPU Operating Properly (COP) watchdog will reset the module if a processor exception is encountered. Some causes of processor exceptions include:

Watchdog Reset due to TPU Watchdog (value=13)

Some CPUs support a Time Processor Unit (TPU) coprocessor that has its own CPU operating properly watchdog. The module was reset because the TPU watchdog detected a problem. The most common TPU watchdog event is thread starvation where a TPU channel spends too long executing (likely because it is stuck in an endless loop).

Watchdog Reset due to TPU Exception (value=14)

Some CPUs support a Time Processor Unit (TPU) coprocessor. If the TPU detects an exception then the primary CPU watchdog shall issue a reset.

Watchdog Reset due to TPU Memory Signature (value=15)

Some CPUs support a Time Processor Unit (TPU) coprocessor. Some of TPU implementations are able to detect errors in their code store (which often resides in RAM). If such an error is detected then primary CPU watchdog shall issue a reset.

Watchdog Reset due to Fatal Kernel Error (value=16)

The tasking kernel observed a fatal error that it could not recover. This error is issued when internal kernel checks identify inconsistencies in the state of its variables.

Watchdog Reset due to TPU Parameter RAM Validation Failure (value=17)

Some CPUs support a Time Processor Unit (TPU) coprocessor. Communication between the two is handled using a dualport RAM. The host CPU may implement an active memory validation strategy where select regions of the memory are actively interacted with to confirm correct operation. This reset is issued if the TPU is in use to control IO and the CPU detects incorrect behavior of this memory.

Watchdog Reset due to a Rate Group Slip (value=18)

This reset is issued if Rate Group Slip detection is enabled, configured to reset the system and the algorithm detects the periodic trigger slip. Slip Detection can be installed via the Global Periodic Trigger Slip and Execution Metric Definition block or the Explicit Periodic Trigger Slip Definition block.

Invalid Calibration (value=19)

The application detected that the calibration was invalid and MotoHawk was configured to induce a reset in such a circumstance.

Watchdog Reset due to Processor Exception, Suspecting Task stack overrun (value=20)

A processor exception was observed, which can be caused by various conditions including illegal instruction access and illegal memory accesses. Memory corruption caused by a Task Stack Overrun can lead to such illegal accesses occurring. A task stack was detected to have been overrun when the processor exception was observed. Thus it is suspected that the cause of the processor exception is the corruption of memory because of an overrun of a task's stack.

Bad Hardware Lock Use (value=21)

A watchdog reset was issued because a microprocessor's hardware locking silicon was used inappropriately. Hardware locks are used with multicore processors to control synchronization. This form of reset most often implies a software issue.

Hardware Lock Timeout (value=22)

A watchdog reset was issued because the microprocessor's hardware locking silicon resulted in one of the microprocessor's cores timing out while waiting to acquire the lock. Hardware locks are used with multicore processors to control synchronization. A timeout commonly results when the application software remains within a critical section for too long.

Configuration Error (value=23)

A watchdog reset was issued because there was a problem with a low level configuration that was not recoverable.

Critical Section Deadlock (value=24)

A watchdog reset was issued because code executing in a multicore capable OS (such as ControlCore) attempted to obtain a tasking critical section while interrupts were disabled. Such a request could lead to core deadlock and so was detected and considered fatal (gives deterministic operation).

Software Interrupt Service Unavailable (value=25)

A watchdog reset was issued because software was unable to acquire a software interrupt resource. Typically used in multicore environments to push task execution to a specific core.

Unexpected Task Termination (value=26)

A watchdog reset was issued because an executing task that was not expected to terminate was terminated.

Critical Memory Corruption (value=27)

A watchdog reset was issued because critical memory was detected as having suffered corruption (most likely via rogue software execution).

TPU ECC Memory Failure (value=28)

Some microcontrollers support hardware that execute ECC memory checks on Timer Processor Unit (TPU) memory. A watchdog reset was issued because this system observed a memory failure.

Fault Collection Control Unit (value=29)

Some microcontrollers support hardware that collects faults and can issue resets when certain faults are observed.

Fault Output Supervisor Unit (value=30)

Some microcontrollers support hardware that supervises the operation of the FCCU. If that unit does not behave as expected when it encounters a fault then the supervisory unit will issue a reset.

Simultaneous Core Reset (value=31)

Hardware with multiple cores could induce a reset from multiple sources at the same time. In this circumstance the source of the reset is undefined for each of the cores and so a simultaneous reset cause is reported.

Fault Collection Control Unit Access Denied (value=32)

Unexpected reset caused by the Fault Collection Control Unit (FCCU) software driver not being able to access the hardware in order to service a fault.

Unexpected Fault Collection Control Unit Alarm (value=33)

An unexpected Fault Collection Control Unit (FCCU) alarm interrupt service occurred. The FCCU supports alarms that require an interrupt service to execute in order to acknowledge the fault. When this cause of reset is observed the FCCU issued an alarm service for a fault that was not configured for such a service.

Checker Core Out of Lockstep (value=34)

The lockstep checker core was detected as being out of lockstep with core that it was monitoring. If the MCU requires the FCCU to detect this fault then the application needs to include the FCCU Reaction Definition block in the model in order to enable this fault and configure its reaction to be a reset.

Checker Core Disabled (value=35)

The lockstep checker core was detected as being disabled, but lockstep checker core monitoring was expected to be operational. If the MCU requires the FCCU to detect this fault then the application needs to include the FCCU Reaction Definition block in the model in order to enable this fault and configure its reaction to be a reset.

FCCU Alarm Service Timeout (value=36)

The FCCU Reaction Definition block specifies whether a trigger should execute when a fault is detected and also specifies an alarm timeout value. This reset cause is reported when an FCCU fault is detected, the reaction is configured to allow trigger execution, but all the FCCU Reaction Trigger(s) associated with the observed fault do not complete their execution before the timeout expires.

Watchdog Reset due to Multiple uP Exception (value=37)

While attempting to handle a machine check exception that may have been related to a memory ECC problem another core also issued a machine check exception. A reset was issued because the handler could not determine whether the exception could be recovered.

Low or High Voltage Detect (value=38)

A low or high voltage transient caused a reset at a time other than the power on reset.

Unexpected Software Initiated Reset (value=39)

An unexpected software initiated reset occurred. Normally software initiated resets are used to trigger a reset for a known reason. In this case, there is an unknown reason for the software initiated reset to have occurred, or the reset is otherwise unexpected.

External Reset Pin Asserted (value=40)

The external reset pin was asserted and caused a reset sometime after the initial power on reset.

Core Lockup occurred (value=41)

A core lockup event occurred. Typically this is as a result of an unrecoverable exception in the core.