Reset Status / Boot Cause

dsPIC30F dsPIC33F dsPIC33E dsPIC33C dsPIC33A

☀️ Light

The Reset Status / Boot Cause block snapshots the chip’s RCON register at firmware initialization, optionally exposes the raw value on the RCON output port (uint16 on classic dsPIC, uint32 on dsPIC33A), then clears RCON. It also maintains persistent per-cause counters that survive watchdog / software / external resets and reset to zero only on a true power-on. Each output — the RCON snapshot, the ResetEvents total, and every per-cause counter — is exposed as its own port when its checkbox is enabled. If no output is selected the block has no ports and generates no code.

When to use:

• Diagnose why the MCU rebooted — read POR vs BOR vs watchdog vs software vs external (MCLR) reset at boot
• Count reset events — keep persistent per-cause tallies across resets for field diagnostics / health monitoring
• Log a reset reason — feed the RCON output (or a specific <CAUSE>_count) to telemetry on every boot
• Watchdog post-mortem — pair with the Watchdog / Deadman Timer block to confirm a WDTO reset actually occurred

When NOT to use:

• Triggering a reset — use the Reset block to cause a software reset; this block only reports the last one
• Non-dsPIC / PIC32A target — the block needs an RCON register; it is inert on SAM/ARM and PIC32MK/MX/MZ (warns, outputs hold 0)
• Runtime reset-flag polling — RCON is snapshotted and cleared once at boot; it is not re-read every step

Block Dialog

1. Output2. Status

Screenshots taken with chip 33CK256MP508

Overview

At firmware init the block reads RCON once into a volatile global and clears RCON (so the next reset starts from a clean slate). A true power-on is detected via a magic word in persistent RAM (independent of RCON.POR), which is more reliable than RCON.POR across the various brown-out / VREG cold-start signatures. On the first power-up (magic word absent) the counters are initialized to zero and the current boot is not counted; on a warm reset (magic word present, RAM survived) the persistent counter for each cause bit that was set is incremented. So the counters report resets since power-up, not the power-up itself.

The block is chip-aware: it reads the actual RCON bitfields from the chip database, so only the reset-cause checkboxes that physically exist on the selected device are shown. The Behavior field (Status tab) summarizes the available cause bits, the RCON width, and the relevant datasheet section for the detected family.

One block per model. Because there is a single RCON and one set of persistent counters, only one Reset_Status block is allowed; a second instance raises a build error.

What exactly is counted?

The block produces three kinds of output, all derived from the single boot-time RCON snapshot:

• RCON — the raw register value before it is cleared. Multiple bits can be set at once (e.g. POR + BOR on a cold power-up), so this is a bitmask, not a single cause.
• <CAUSE>_count — a persistent counter incremented on a warm reset whenever that specific RCON bit was set. Enabled per checkbox. Survives WDT / software / external resets; zeroed (and not counted) on a true power-on / RAM-losing reset.
• ResetEvents — a persistent counter incremented once per warm reset event when any true reset-cause bit is set. It is not the arithmetic sum of the per-cause counters: if POR and BOR co-assert on a warm reset, POR_count and BOR_count each increment, but ResetEvents increments only once.

Reset causes (counted by ResetEvents): POR, BOR, WDTO, SWR, EXTR, CM, IOPUWR, TRAPR.

Wake / status flags (diagnostic counters only, never counted by ResetEvents): IDLE, SLEEP, VREGS, VREGSF. These represent low-power wake or regulator status, not an actual device reset.

Worked examples

What happens at boot for a few common RCON snapshots on a classic dsPIC (counters assumed enabled). Note the first cold power-up is not counted (RAM not yet initialized); all rows except the first therefore describe a warm reset whose persistent RAM survived:

The first power-up boot is not counted. On the very first boot of a freshly programmed device (or after any reset that loses RAM, e.g. a true power-loss POR), the magic word in persistent RAM is uninitialized, so all counters are initialized to zero and the current boot is not counted. Counting begins on the next (warm) reset, whose persistent RAM survived. A cold power-up therefore lands at POR_count = 0, BOR_count = 0, ResetEvents = 0; a subsequent watchdog reset then makes WDTO_count = 1, ResetEvents = 1. This is by design — the counters report resets since the device first powered up, not the power-up itself.

Ports

Port order is RCON (if enabled) first, then ResetEvents, then the per-cause counters. All counter outputs are persistent — they survive non-POR resets and zero on power-on. If RCON, ResetEvents and every per-cause counter are all unchecked, the block has zero output ports and generates no code.

Parameters

Output tab

Checkboxes for cause bits the selected chip does not have are hidden automatically (driven by the chip database, not a hardcoded list) — so a tooltip only ever appears for a cause the targeted device actually supports. See Reset-cause availability by family below for which causes each family exposes.

Status tab

Reset-cause availability by family

The set of RCON cause bits differs per family; the block shows only what exists:

(Exact set is resolved at compile time from the chip database — the table above is indicative.)

Code generation

• Snapshot + clear — at Start the block reads RCON into a volatile global, runs the magic-word POR check, then clears RCON. Counter increments run only on a warm reset (the else branch of the magic-word check) so the first power-up is never counted.
• Persistent counters — __attribute__((persistent)) globals (one per enabled cause + optional total) survive WDT/SW/EXT resets; on a true cold start (RAM lost) the magic word mismatches and they are zeroed without counting.
• No output selected — if RCON, ResetEvents and every per-cause counter are unchecked, the block emits no globals, no Start code and no output ports (it does nothing).
• Unsupported target — emits nothing: no globals, no persistent state; if RCON output is enabled it holds 0, the model still compiles.
• Width — the RCON port and counters are typed uint16 (classic) / uint32 (33A) consistently in both simulation and generated code.

Examples

Programmatic setup — log the boot cause over UART

mdl = 'my_model';
add_block('MCHP_Blockset/System Configuration/Microchip Master', [mdl '/Master']);
add_block('MCHP_Blockset/System Functions/Reset_Status', [mdl '/BootCause']);

% Expose the watchdog-reset tally and the raw RCON word.
set_param([mdl '/BootCause'], 'Provide_WDTO_count', 'on');
set_param([mdl '/BootCause'], 'CounterWidth', 'uint16');

% Route RCON / WDTO_count to a UART Tx block for telemetry on boot.

Pairing with the Watchdog block

% Watchdog resets the MCU on a missed deadline ...
add_block('MCHP_Blockset/System Functions/Watchdog_DMT', [mdl '/WDT']);
set_param([mdl '/WDT'], 'Mechanism', 'Standard WDT', 'TimeoutChoice', '1 (s)');

% ... and Reset_Status confirms a WDTO reset actually happened, with a count.
add_block('MCHP_Blockset/System Functions/Reset_Status', [mdl '/BootCause']);
set_param([mdl '/BootCause'], 'Provide_WDTO_count', 'on');

Device Support

Related Blocks

• Reset — issues a software reset (this block reports the cause of the last one)
• Watchdog / Deadman Timer — the WDT/DMT whose WDTO reset this block can confirm and count
• Reset Config — selects which reset sources (BOR, MCLR, software) are enabled on the chip
• MCHP Master — target selection; the block reads the chip’s RCON definition from the database it populates