Diagnosing Common Causes of System Crashes

Few things are more frustrating than your system running perfectly for ten minutes and then suddenly crashing. Unfortunately, your board crashing is just a symptom, not a cause. While your board can crash for many reasons, most crashes are typically caused by one of three things: hard faults, stack overflows, and watchdog timer resets.

In this guide, we will learn more about these three common causes of crashes and how to diagnose them on the Texas Instruments CC2340 series and Nordic Semiconductor 54 L series development boards.

Hard Faults

A hard fault is a system error that occurs when the processor attempts an illegal operation that the hardware cannot recover from. It is usually triggered by bad memory operations, such as dereferencing a NULL pointer, accessing an unaligned memory address, or trying to execute code from a region of memory that is not executable.

On the TI CC2340R5 LaunchPad, FreeRTOS makes it easy to diagnose a hard fault. Once the fault occurs, the CPU automatically saves the crash state into the Process Stack Pointer (PSP), which includes multiple register values. Notably, one of the registers saved is the Program Counter (PC), which holds the address of the instruction that caused the crash.

Example

Follow the steps below on your TI CC2340R5 board to learn how you can identify and diagnose a hard fault. You can also use these instructions with your Nordic nRF54L15 board, but some of the byte offsets may differ.

Start by adding the following code to your firmware and calling it within your main function.

void trigger_hard_fault(void) {
    // Pointer to address 0 (NULL)
    volatile uint32_t *bad_ptr = (uint32_t *)0x00000000;
    
    // Try to write to a read-only or invalid region
    *bad_ptr = 0xDEADBEEF; 
}

Build your firmware and start debugging. In the Memory view, find the PSP location, and look for the 7th word. Then, put the 7th word into the Disassembly view, and you’ll be able to see what line of code caused your hard fault.

Stack Overflow

A stack overflow is a system error that occurs when the stack (the memory reserved for local variables and function call tracking) overgrows its limits and spills into other memory regions. It is usually caused by functions that declare large arrays or code that uses deeply nested function calls, especially recursion. In embedded systems, stack sizes are fixed and typically very small, so you frequently run the risk of encountering a stack overflow.

The TI CC2340R5 makes it easy for you to diagnose a stack overflow. TI has a built-in stack overflow checker option in the project config that, when enabled, automatically detects a stack overflow for you.

Example

Follow the steps below on your TI CC2340R5 board to learn how you can identify and diagnose a stack overflow. The specific instructions for your Nordic nRF54L15 board may be a little different, but the workflow is the same.

Start by enabling the “Stack Overflow Checking” option in your project’s SysConfig.

Then, add the following code to your firmware and call it within your main function.

void cause_overflow(int counter) {
    // Create local array to make each function call use 64 bytes
    volatile uint8_t big_buffer[64]; 
    big_buffer[0] = (uint8_t)counter;

    // Recursive call
    cause_overflow(counter + 1);

    // Prevent tail-call optimization
    big_buffer[0] = (uint8_t)(counter - 1);
}

Build your firmware and start debugging. In the Runtime (RTOS) Object view, select Task for Module name and Detailed for View name. Find the StackPeak value for your mainThread and compare it to the StackSize value. If StackPeak is greater than StackSize, you have a stack overflow on your hands.

Watchdog Timer Resets

A watchdog timeout is a hardware-level safety mechanism that automatically resets the microcontroller if the firmware stops running for too long. Specifically, the watchdog timeout occurs only when your code gets stuck in an infinite loop or when a long-running task doesn’t proactively manage the watchdog timer.

All you need to determine whether your TI CC2340R5 experienced a watchdog reset is to look at the CPU’s watchdog register.

Example

Follow the steps below on your TI CC2340R5 board to learn how you can identify and diagnose a watchdog reset. The specific instructions for your Nordic nRF54L15 board may be a little different, but the workflow is the same.

Start by creating a watchdog instance in your project’s SysConfig.

Then, add the following code to your firmware and call it within your main function.

#include <ti/drivers/Watchdog.h>

void trigger_watchdog_reset(void) {
    Watchdog_Handle watchdog;
    Watchdog_Params params;

    Watchdog_init();
    Watchdog_Params_init(&params);
    
    // Set to Reset Mode (Standard behavior)
    params.resetMode = Watchdog_RESET_ON;
    watchdog = Watchdog_open(CONFIG_WATCHDOG_0, &params);

    if (watchdog == NULL) {
        // Error opening Watchdog
        while (1);
    }

    // Simulate hang to trigger watchdog timer reset
    while(1); 
}

Build your firmware and start debugging. Your board may restart and disconnect. Once it’s back online, reconnect your debugger, and then open the Registers view. Under PMCTL > RSTSTA > SYSSRC, you should see a Watchdog Timeout Event.

Common Crashes Cheatsheet

Here’s how to distinguish among the three common causes of system crashes.

Wrapping Up

When your board crashes, it’s just telling you that the hardware reached an undefined state. When you understand the differences between a hardware fault, a memory overflow, and a watchdog reset, you can stop guessing what went wrong and jump to fixing the root cause. Whether you are debugging the Nordic nRF54L15 or the TI CC2340R5, you will always capture the fault first and then inspect the system memory for clues.

With this new knowledge, you should feel confident moving forward in your firmware development journey.

Ready to connect your devices anywhere on Earth? Get started with Hubble Network for free →