Building More Fault-Tolerant Embedded C++ Applications for Radiation-Prone ARM Systems

By the end of this page, you will understand how software can help an embedded C++ system survive transient faults such as bit flips, corrupted state, and unexpected crashes. You will learn practical fault-tolerance techniques including validation, checksums, redundancy, watchdog recovery, safer state handling, and defensive build choices for ARM/GCC-based systems.

What is the core concept?

The main concept here is software fault tolerance in embedded systems.

In radiation-prone environments, a running program may experience soft errors:

• a bit flips in RAM
• a CPU register becomes corrupted
• a stored function pointer or state value changes unexpectedly
• a calculation produces a wrong result because an intermediate value was altered

These faults are often transient. The hardware is not permanently broken, but the current computation or stored state may be wrong.

Why normal correct code may still fail

A program can be logically correct and still fail in this kind of environment because it usually assumes:

• memory contents remain stable
• variables only change through program logic
• control flow follows compiled instructions exactly

Soft errors break those assumptions.

What software can do

Software usually cannot prevent radiation-induced faults by itself, but it can:

• detect that something is wrong
• contain the damage before it spreads
• recover by resetting or rebuilding state
• reduce risk by avoiding fragile patterns

Common software strategies

1. Detect invalid state early

Use:

• range checks
• sanity checks
• magic numbers
• sequence counters
• assertions in test builds
• checksums or CRCs for important data structures

2. Prefer recoverable designs

Think of your program as a worker following a checklist in a room where, once in a while, someone randomly changes one character on the paper.

If the worker blindly trusts the checklist forever, eventually they may:

• read the wrong number
• skip a step
• write a bad result
• crash the process

A fault-tolerant program behaves more like a careful worker who:

• double-checks important values
• verifies labels before using a box
• throws away suspicious input
• restarts from a known good checkpoint when confused

So the mental model is:

• normal programming = "my data changes only when I change it"
• fault-tolerant programming = "my data may become wrong at any time, so I must verify important assumptions"

Core defensive patterns in embedded C++

1. Range checking critical values

bool is_valid_temperature(int temp) {
    return temp >= -40 && temp <= 125;
}

This prevents obviously corrupted values from being treated as real sensor data.

2. Store critical data with a checksum

#include <cstdint>

struct Config {
    uint32_t mode;
    uint32_t threshold;
    uint32_t checksum;
};

uint32_t simple_checksum(uint32_t a, uint32_t b) {
    return a ^ b ^ 0xA5A5A5A5u;
}

void update_config(Config& cfg, uint32_t mode, uint32_t threshold) {
    cfg.mode = mode;
    cfg.threshold = threshold;
    cfg.checksum = simple_checksum(mode, threshold);
}

bool config_is_valid(const Config& cfg) {
     cfg.checksum == (cfg.mode, cfg.threshold);
}

Example: validating critical state before use

#include <cstdint>

struct SafeCounter {
    uint32_t value;
    uint32_t inverted;
};

void set_counter(SafeCounter& c, uint32_t v) {
    c.value = v;
    c.inverted = ~v;
}

bool counter_is_valid(const SafeCounter& c) {
    return c.inverted == ~c.value;
}

bool increment_counter(SafeCounter& c) {
    if (!counter_is_valid(c)) {
        return false;
    }

    set_counter(c, c.value + 1);
    return true;
}

Step-by-step

1. set_counter(c, 10) stores:

   • value = 10
   • inverted = ~10

2. increment_counter(c) starts.

Where these techniques are used

Radiation-exposed embedded systems

• satellites
• avionics at high altitude
• nuclear inspection equipment
• scientific instruments

These systems often combine hardware protection with software checks and recovery.

Industrial control systems

A controller may validate sensor values and reject impossible readings before using them to drive actuators.

Safety-oriented firmware

Firmware may store configuration with CRCs and only accept values that pass integrity checks.

Communications stacks

Packets often include:

• checksums
• CRCs
• sequence numbers
• retries

This is fault tolerance applied to transmitted data.

Long-running unattended devices

Remote devices may use:

• watchdogs
• reboot counters
• persistent fault logs
• startup self-checks

These help the system recover when nobody is physically present.

How teams use these ideas in real projects

Guard clauses for corrupted input or state

Developers often validate early and return immediately if something looks wrong.

bool handle_message(const Message& msg) {
    if (!msg.has_valid_crc()) {
        return false;
    }

    if (!is_known_message_type(msg.type)) {
        return false;
    }

    return process_message(msg);
}

This keeps bad data from moving deeper into the system.

Early return to a safe mode

A common embedded pattern is:

• detect corruption
• stop normal operation
• switch outputs to a safe state
• wait for reset or recovery

Validation around persistent configuration

Real systems often store configuration in non-volatile memory with:

• version fields
• size fields
• CRCs
• default fallback values

Rebuild state instead of trusting cached state

If state can be recomputed from hardware inputs or a trusted source, many teams prefer to rebuild it rather than keep a large mutable in-memory structure.

Error counters and health monitoring

1. Assuming every crash is caused by radiation

Sometimes the problem is an ordinary software bug.

Broken example

int values[4] = {1, 2, 3, 4};
int x = values[10];

This is an out-of-bounds access, not a soft error.

How to avoid it

• enable warnings
• run static analysis
• test with sanitizers where possible
• review pointer and array usage carefully

2. Trusting critical state without validation

Broken example

current_mode = static_cast<Mode>(raw_mode);
run_mode_logic(current_mode);

If raw_mode is corrupted, the program may enter an invalid state.

Better

if (!is_valid_mode(raw_mode)) {
    enter_safe_mode();
} else {
    current_mode = static_cast<Mode>(raw_mode);
}

3. Keeping too much mutable global state

Large amounts of shared writable state are harder to validate and recover.

Related approaches compared

Quick reference

Main goal

Make embedded software detect, contain, and recover from transient corruption.

Good practices

• Validate all critical inputs and state
• Keep critical state small and easy to check
• Store important data with CRC/checksum/version
• Use watchdogs for recovery
• Fail safe when state is invalid
• Log fault counters for diagnosis
• Remove ordinary bugs with warnings and testing

Useful defensive patterns

if (!is_valid(value)) {
    enter_safe_mode();
    return false;
}

stored_crc = compute_crc(data);
if (stored_crc != compute_crc(data)) {
    mark_fault();
}

safe.value = x;
safe.inverted = ~x;

GCC/testing ideas

-Wall -Wextra -Wshadow -Wconversion

-fsanitize=address,undefined

Important reminder

• Compiler flags help find bugs before deployment

What is a soft error in embedded systems?

A soft error is a temporary fault, often caused by radiation or electrical disturbance, that changes data or computation without permanently damaging the hardware.

Can GCC compiler flags prevent radiation-induced bit flips?

No. Compiler flags cannot stop bit flips in deployed memory or registers. They can help eliminate normal software bugs and improve build quality.

How can C++ code detect memory corruption?

Common methods include CRCs, checksums, duplicated critical values, range checks, version fields, and validation before using important state.

Is a watchdog enough to make firmware fault-tolerant?

No. A watchdog helps with recovery from hangs or severe faults, but it should be combined with validation, safe-state behavior, and integrity checks.

Should I use assertions in embedded systems?

Yes, especially in development and test builds. In production, use deliberate runtime validation and safe recovery paths for important conditions.

How do I tell the difference between a software bug and a radiation fault?

Use strong testing, sanitizers, and logging. If ordinary bugs are removed first, remaining rare unexplained corruption events are easier to classify.

What data should be protected first?

Start with safety-critical and control-critical data such as configuration, state-machine state, counters, function pointers, command packets, and actuator-related values.

Related concepts

• Embedded systems reliability — broader design approach for keeping firmware dependable over long periods.
• Defensive programming — writing code that checks assumptions and handles invalid state safely.
• Watchdog timers — hardware or software recovery mechanism for hangs and stalled execution.
• Checksums and CRCs — common ways to detect corrupted data.
• State machines — important because corrupted state values can lead to dangerous control flow.
• Assertions — useful for catching invalid assumptions during testing.
• Static analysis — helps remove ordinary bugs before deployment.
• Undefined behavior in C++ — critical because memory and logic bugs can mimic environmental faults.
• ECC memory — hardware technique related to software fault-tolerance strategies.
• Fail-safe design — ensures the system moves to a safe condition when corruption is detected.