Detecting and Managing Reset Causes on ARM Cortex-M3 (STM32F107) for External Hardware Circuits

ARM Cortex-M3 Reset Behavior and External Hardware Reset Requirements

The ARM Cortex-M3 processor, as implemented in the STM32F107 microcontroller, does not natively support direct control of the nRST pin via software instructions. This limitation becomes particularly challenging when designing systems where the microcontroller must manage the reset behavior of external hardware circuits. In such scenarios, the microcontroller often boots up before the external hardware due to differences in power supply stabilization times. This asynchrony necessitates a mechanism to ensure that the external hardware is properly reset after the microcontroller has initialized.

The core issue revolves around generating a delayed reset signal from the microcontroller to the external hardware circuit without causing an infinite reset loop. Specifically, the microcontroller must differentiate between a power-on reset and a reset triggered by its own actions. This differentiation is crucial to prevent the system from entering a state where the microcontroller continuously resets itself and the external hardware.

The STM32F107 microcontroller, like other Cortex-M3 devices, provides a System Reset Request (SYSRESETREQ) feature that can be used to trigger a system reset. However, this feature does not directly control the nRST pin. Instead, it initiates a system reset that may or may not propagate to the nRST pin, depending on the specific implementation by the chip manufacturer (in this case, STMicroelectronics).

SYSRESETREQ Limitations and GPIO-Based Reset Solutions

The primary limitation of the SYSRESETREQ feature is that it does not provide direct control over the nRST pin. This means that while the microcontroller can reset itself, it cannot directly assert a reset signal to external hardware connected to the nRST pin. To address this, a GPIO pin can be used to generate the reset signal for the external hardware. This approach requires a small hardware modification but provides the necessary control over the reset signal.

The use of a GPIO pin for reset generation introduces additional complexity in terms of software implementation. The microcontroller must be programmed to assert the reset signal at the appropriate time and ensure that it does not inadvertently trigger a reset loop. This involves detecting the cause of the reset and differentiating between a power-on reset and a reset triggered by the microcontroller itself.

The STM32F107 microcontroller provides several registers that can be used to determine the cause of a reset. These include the Reset and Clock Control (RCC) registers, which contain flags indicating the source of the last reset. By examining these flags, the microcontroller can determine whether the reset was caused by a power-on event, a software reset, or another source. This information can then be used to control the behavior of the GPIO-based reset signal.

Implementing Reset Cause Detection and GPIO-Based Reset Control

To implement a robust reset management system on the STM32F107 microcontroller, the following steps should be taken:

1. Initialize the GPIO Pin for Reset Control: Configure a GPIO pin as an output to serve as the reset signal for the external hardware. This pin should be initialized to a high state (inactive) during the microcontroller’s startup sequence.

2. Detect the Reset Cause: After the microcontroller boots up, read the RCC registers to determine the cause of the last reset. If the reset was caused by a power-on event, proceed to assert the reset signal to the external hardware. If the reset was caused by a software reset or another source, skip the reset signal assertion to avoid a reset loop.

3. Assert the Reset Signal: If a power-on reset is detected, assert the reset signal by driving the GPIO pin low for a specified duration. This duration should be sufficient to ensure that the external hardware is properly reset. After the reset duration has elapsed, release the reset signal by driving the GPIO pin high.

4. Prevent Reset Loops: Ensure that the microcontroller does not reassert the reset signal on subsequent resets. This can be achieved by setting a flag in non-volatile memory (such as a backup register or EEPROM) after the reset signal has been asserted. On subsequent resets, check this flag to determine whether the reset signal has already been asserted and avoid reasserting it.

5. Handle Edge Cases: Consider edge cases such as brown-out conditions, watchdog resets, and external reset signals. Ensure that the reset management system behaves correctly in all scenarios and does not inadvertently trigger a reset loop.

By following these steps, the STM32F107 microcontroller can effectively manage the reset behavior of external hardware circuits without requiring significant hardware modifications. The use of a GPIO pin for reset control provides the necessary flexibility, while the detection of reset causes ensures that the system operates reliably and avoids reset loops.

Detailed Implementation Example

To illustrate the implementation of the reset management system, consider the following example using the STM32F107 microcontroller:

#include "stm32f10x.h"

#define RESET_GPIO_PORT GPIOA
#define RESET_GPIO_PIN GPIO_Pin_0
#define RESET_DURATION_MS 100

void GPIO_Configuration(void) {
    GPIO_InitTypeDef GPIO_InitStructure;

    // Enable GPIOA clock
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE);

    // Configure RESET_GPIO_PIN as output
    GPIO_InitStructure.GPIO_Pin = RESET_GPIO_PIN;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_Init(RESET_GPIO_PORT, &GPIO_InitStructure);

    // Set RESET_GPIO_PIN high (inactive)
    GPIO_SetBits(RESET_GPIO_PORT, RESET_GPIO_PIN);
}

void Reset_External_Hardware(void) {
    // Set RESET_GPIO_PIN low (active)
    GPIO_ResetBits(RESET_GPIO_PORT, RESET_GPIO_PIN);

    // Wait for the reset duration
    Delay_ms(RESET_DURATION_MS);

    // Set RESET_GPIO_PIN high (inactive)
    GPIO_SetBits(RESET_GPIO_PORT, RESET_GPIO_PIN);
}

int main(void) {
    // Initialize GPIO for reset control
    GPIO_Configuration();

    // Check the reset cause
    if (RCC_GetFlagStatus(RCC_FLAG_PORRST) != RESET) {
        // Power-on reset detected, reset external hardware
        Reset_External_Hardware();

        // Clear the power-on reset flag
        RCC_ClearFlag();
    }

    // Main application loop
    while (1) {
        // Application code here
    }
}

In this example, the GPIO_Configuration function initializes the GPIO pin used for reset control. The Reset_External_Hardware function asserts the reset signal by driving the GPIO pin low for a specified duration and then releases it. The main function checks the reset cause using the RCC_GetFlagStatus function and resets the external hardware if a power-on reset is detected. The power-on reset flag is then cleared to prevent the reset signal from being reasserted on subsequent resets.

Conclusion

Managing reset behavior in systems with multiple hardware components can be challenging, particularly when the microcontroller and external hardware have different power-up sequences. The ARM Cortex-M3 processor, as implemented in the STM32F107 microcontroller, does not provide direct control over the nRST pin, necessitating the use of a GPIO pin for reset control. By detecting the reset cause and carefully managing the reset signal, it is possible to ensure that the external hardware is properly reset without causing an infinite reset loop. This approach requires careful software implementation but provides a reliable solution for managing reset behavior in complex embedded systems.