Reset - Software Reset

dsPIC30F dsPIC33F dsPIC33E dsPIC33C dsPIC33A PIC32

☀️ Light

The Reset block triggers a software chip reset whenever any element of its input signal becomes non-zero. Typical use — recovery from an unrecoverable fault, forced reboot after firmware update, or host-commanded reset.

When to use:

• Fault recovery — unrecoverable error detected by application logic (persistent overcurrent, corrupt configuration, stuck state machine)
• Host-commanded reboot — UART / CAN / I²C command from an upstream supervisor asks the MCU to restart
• Post-update reboot — application signals end-of-firmware-update and wants to restart into the new image
• Test harness — automated test triggers a reset between test cases to bring the MCU back to a known state

When NOT to use:

• Benign conditions — do not reset on expected transient events; handle them in the control loop
• Periodic health reset — a scheduled reset every N minutes is usually a design smell; investigate the root cause first
• Watchdog substitute — use the watchdog peripheral (MCHP Master → Watchdog) for missed-deadline recovery; the Reset block is an explicit, not a safety-net, mechanism
• Holding a peripheral in reset — for peripheral reset (e.g. an I²C bus recovery), drive the peripheral’s own reset bit, not the whole MCU

Overview

The Reset block samples its trigger input at its block sample time and issues a software chip reset when any element of that input becomes non-zero. On dsPIC it expands to the __asm__ volatile("RESET") instruction; on PIC32 and SAM families the equivalent SoftReset() / NVIC_SystemReset() call is emitted.

Because the effect is a full chip reset, any code after the trigger is never executed — the MCU restarts from the reset vector and re-runs the initialization sequence (oscillator setup, peripheral configuration, main()).

Ports

The block has no outputs.

Parameters

The Reset block has no other user-facing parameters — it is intentionally minimalist.

Device Support

Available on every family that ships a Mchp_reset() atomic-function implementation in its TLC. At the time of writing:

Examples

Programmatic Setup

mdl = 'my_model';

% Add the Reset block
add_block('MCHP_Blockset/System Functions/Reset', [mdl '/ChipReset']);

% The only mask parameter is Sample Time; leave inherited unless you
% need an explicit rate.
% set_param([mdl '/ChipReset'], 'SampleTime', '0.01');

% Drive the trigger from a fault condition produced elsewhere in the model.
% Example: route a boolean flag computed by a subsystem named 'FaultMon'.
add_line(mdl, 'FaultMon/1', 'ChipReset/1', 'autorouting', 'on');

Example 1 — Host-commanded reset over UART

A supervisor board sends the ASCII character 'R' (0x52) to request a reboot. A small decoder subsystem compares the received byte against the constant and drives the Reset block.

UART Rx ─► [==0x52?] ─► Reset

Example 2 — Watchdog-detected reset recovery

The Microchip Master block enables the hardware watchdog. The application clears it in the main task. If the main task hangs, the hardware watchdog resets the MCU automatically — no Reset block needed for that path. Use the Reset block instead for explicit faults detected before the watchdog would have expired, so the firmware logs a clean “reset reason = software fault” before rebooting.

References

• Microchip Datasheet, “Device Reset” chapter — lists every reset source (POR, BOR, MCLR, watchdog, software reset) and how to distinguish them on boot (RCON register for dsPIC, RSTC for SAM).
• XC-DSC / XC16 / XC32 compiler user guides — reference for the RESET assembly mnemonic (dsPIC) and SoftReset() / NVIC_SystemReset() intrinsics.

Related Blocks

• Simulink Reset Config — configures which reset sources are enabled on the chip (BOR, MCLR, software). Complementary to this block.
• MCHP Master — master configuration block; Master’s Debug tab enables the hardware watchdog that provides automatic (non-commanded) recovery.
• Interrupt — an Interrupt block with an on-trap handler can be paired with Reset to log diagnostics before rebooting.