# STM32 Power-Up and Power-Down Sequencing for RF Subsystem Management: Complete Implementation Guide

> Master STM32 power-up and power-down sequencing for RF subsystem management. Implement reliable control for PA supply rails using GPIO with this complete guide.

- Repository: [NawfalMotii79/PLFM_RADAR](https://github.com/NawfalMotii79/PLFM_RADAR)
- Tags: how-to-guide
- Published: 2026-08-20

---

**The PLFM RADAR firmware controls RF power-amplifier rails through GPIO-controlled sequencing on STM32 F7, with `EN_DIS_RFPA_VDD_Pin` on `GPIO_PIN_6`/`GPIOD` serving as the primary enable for the PA supply rail.**

STM32 power-up and power-down sequencing for RF subsystem management is critical in radar systems where a mis-timed enable can destroy expensive GaN PAs or create hazardous bias conditions. The PLFM RADAR project demonstrates production-ready sequencing logic using HAL GPIO drivers, explicit delay insertion, and hardware-protected emergency shutdown paths. This article examines the exact implementation found in the open-source firmware, including the pin definitions, initialization flow, and fault-handling routines that keep the RF front-end within safe operating limits.

## Pin Mapping for RF-PA Power Rails

All power-rail signals are centralized in [`9_Firmware/9_1_Microcontroller/9_1_3_C_Cpp_Code/main.h`](https://github.com/NawfalMotii79/PLFM_RADAR/blob/main/9_Firmware/9_1_Microcontroller/9_1_3_C_Cpp_Code/main.h). The primary PA supply enable is defined as:

```c
/* main.h – pin definitions */
#define EN_DIS_RFPA_VDD_Pin        GPIO_PIN_6
#define EN_DIS_RFPA_VDD_GPIO_Port  GPIOD

```

This pin drives the external load switch or regulator that supplies **RFPA VDD**, typically generated at a lower voltage than the PA drain supply to enable gate bias establishment before full drain voltage is applied.

## Power-Up Sequence Implementation

The firmware follows a four-stage hardware bring-up that ensures bias-before-drain sequencing. Each stage waits for hardware settlement before proceeding.

### Stage 1: Enable Board-Level Rails

The firmware first enables auxiliary 5 V and 5.5 V rails defined by `EN_P_5V0_PA1_Pin`, `EN_P_5V0_PA2_Pin`, and `EN_P_5V5_PA_Pin`. These supply the bias generation and protection circuitry.

### Stage 2: Assert RFPA VDD Enable

The core PA logic supply is enabled via the dedicated GPIO:

```c
/* Power-up RFPA VDD */
HAL_GPIO_WritePin(EN_DIS_RFPA_VDD_GPIO_Port, EN_DIS_RFPA_VDD_Pin, GPIO_PIN_SET);

/* Small delay to let the rail settle */
HAL_Delay(5);

```

The 5 ms delay allows the LDO or buck regulator to reach regulation before the bias DACs are programmed.

### Stage 3: Initialize RF Synthesizers

With the PA logic supply stable, the ADF4382A PLLs are configured via the manager in [`adf4382a_manager.c`](https://github.com/NawfalMotii79/PLFM_RADAR/blob/main/adf4382a_manager.c):

```c
ADF4382A_Manager *mgr = ADF4382A_Manager_Create(...);
ADF4382A_SetOutputPower(mgr, 12, 12);   // TX/RX channel power levels

```

The synthesizer driver in [`adf4382.c`](https://github.com/NawfalMotii79/PLFM_RADAR/blob/main/adf4382.c) handles SPI register programming and lock detection.

### Stage 4: Release PA Gate Control

After lock confirmation, the firmware clears the DAC gate-close pins (`DAC_1_VG_CLR_Pin`, `DAC_2_VG_CLR_Pin`), allowing the PA to amplify the generated RF signals rather than remain in a protected pinch-off state.

## Emergency Stop and Power-Down Sequence

Fault conditions—including PA over-current, bias over-voltage, or watchdog expiration—trigger an immediate shutdown. The emergency stop routine prioritizes cutting the RFPA VDD rail first, then disabling supporting supplies.

### Rail Shutdown Implementation

The unit test in [`test_gap3_emergency_stop_rails.c`](https://github.com/NawfalMotii79/PLFM_RADAR/blob/main/test_gap3_emergency_stop_rails.c) validates the exact GPIO sequence:

```c
/* In the Emergency_Stop routine – rail shutdown */
HAL_GPIO_WritePin(EN_DIS_RFPA_VDD_GPIO_Port,
                  EN_DIS_RFPA_VDD_Pin,
                  GPIO_PIN_RESET);   // <-- disables RFPA VDD

```

The test uses a mock framework to assert that:

- Port `GPIOD` is targeted
- Pin `GPIO_PIN_6` receives `GPIO_PIN_RESET`
- The call occurs at the expected sequence position

This verification ensures that pin remapping in [`main.h`](https://github.com/NawfalMotii79/PLFM_RADAR/blob/main/main.h) does not silently break the safety function.

### Complete Emergency Stop Function

```c
/* Emergency-Stop routine – cuts all PA rails */
void Emergency_Stop(void)
{
    /* Disable RFPA VDD first */
    HAL_GPIO_WritePin(EN_DIS_RFPA_VDD_GPIO_Port,
                      EN_DIS_RFPA_VDD_Pin,
                      GPIO_PIN_RESET);

    /* Disable other PA supplies */
    HAL_GPIO_WritePin(EN_P_5V0_PA1_GPIO_Port, EN_P_5V0_PA1_Pin, GPIO_PIN_RESET);
    HAL_GPIO_WritePin(EN_P_5V5_PA_GPIO_Port,  EN_P_5V5_PA_Pin,  GPIO_PIN_RESET);
    /* … additional rail disables … */

    /* Keep watchdog alive while we stay in the infinite safety loop */
    while (1) {
        IWDG_Refresh(&hiwdg);
    }
}

```

The infinite loop with watchdog refresh prevents a hung processor from leaving the PA in an indeterminate state. If the software fails to call `IWDG_Refresh()`, the independent watchdog expires and forces a hard reset, re-initializing the system to a known-safe state.

## Watchdog Integration During Fault Handling

The [`test_gap3_iwdg_config.c`](https://github.com/NawfalMotii79/PLFM_RADAR/blob/main/test_gap3_iwdg_config.c) unit test confirms that the emergency loop services the watchdog faster than the configured timeout period:

```c
/* Verify watchdog refresh in safety loop */
IWDG_Refresh(&hiwdg);  // Called within while(1) in Emergency_Stop

```

This design satisfies functional safety requirements: the fault handler cannot itself become a source of permanent hardware damage through software lock-up.

## Why Sequencing Order Matters in RF Subsystems

Three failure modes drive the strict ordering requirements in the PLFM RADAR implementation:

- **RF-PA over-current**: Hot-switching the PA drain without established gate bias causes excessive current draw through the output stage, potentially destroying the device.

- **Bias protection vulnerability**: The bias circuitry operates at lower voltage and current limits; powering it after the PA drain exposes it to transient over-voltage conditions.

- **Watchdog safety coverage**: A fault handler that blocks without watchdog refresh could stall indefinitely. The explicit `IWDG_Refresh()` call in `Emergency_Stop()` ensures that any secondary software failure still results in eventual reset and safe state recovery.

## Source File Reference

| File | Purpose | Location |
|------|---------|----------|
| [`main.h`](https://github.com/NawfalMotii79/PLFM_RADAR/blob/main/main.h) | GPIO pin definitions including `EN_DIS_RFPA_VDD_Pin` | [`9_Firmware/9_1_Microcontroller/9_1_3_C_Cpp_Code/main.h`](https://github.com/NawfalMotii79/PLFM_RADAR/blob/main/9_Firmware/9_1_Microcontroller/9_1_3_C_Cpp_Code/main.h) |
| [`test_gap3_emergency_stop_rails.c`](https://github.com/NawfalMotii79/PLFM_RADAR/blob/main/test_gap3_emergency_stop_rails.c) | Unit test validating emergency stop GPIO sequence | `9_Firmware/9_1_Microcontroller/tests/` |
| [`test_gap3_iwdg_config.c`](https://github.com/NawfalMotii79/PLFM_RADAR/blob/main/test_gap3_iwdg_config.c) | Watchdog refresh verification in fault loops | `9_Firmware/9_1_Microcontroller/tests/` |
| [`adf4382a_manager.c`](https://github.com/NawfalMotii79/PLFM_RADAR/blob/main/adf4382a_manager.c) | Synthesizer manager for post-power-up RF configuration | `9_Firmware/9_1_Microcontroller/9_1_1_C_Cpp_Libraries/` |
| [`adf4382.c`](https://github.com/NawfalMotii79/PLFM_RADAR/blob/main/adf4382.c) | Low-level PLL driver with lock detection | `9_Firmware/9_1_Microcontroller/9_1_1_C_Cpp_Libraries/` |

## Summary

- **Primary enable**: `EN_DIS_RFPA_VDD_Pin` on `GPIOD` pin 6 controls the RFPA logic supply in the PLFM RADAR firmware.

- **Power-up order**: Enable core rails → assert RFPA VDD → configure synthesizers → release PA gate, with explicit `HAL_Delay(5)` for rail settling.

- **Emergency shutdown**: Immediate `GPIO_PIN_RESET` of `EN_DIS_RFPA_VDD_Pin`, followed by auxiliary rail disable and watchdog-serviced infinite loop.

- **Safety verification**: Unit tests in [`test_gap3_emergency_stop_rails.c`](https://github.com/NawfalMotii79/PLFM_RADAR/blob/main/test_gap3_emergency_stop_rails.c) and [`test_gap3_iwdg_config.c`](https://github.com/NawfalMotii79/PLFM_RADAR/blob/main/test_gap3_iwdg_config.c) automate validation of both shutdown GPIO writes and watchdog behavior.

- **HAL abstraction**: All sequencing uses `HAL_GPIO_WritePin()` from the STM32 HAL, ensuring portability across F7 family variants.

## Frequently Asked Questions

### What happens if RFPA VDD is enabled before the bias rails?

The PA gate bias circuitry receives no power, leaving the output stage uncontrolled. When drain voltage appears, the PA draws excessive quiescent current, risking thermal damage or immediate device failure. The PLFM RADAR firmware prevents this by sequencing auxiliary 5 V rails before `EN_DIS_RFPA_VDD_Pin`.

### How does the firmware protect against a stuck emergency stop routine?

The `Emergency_Stop()` function enters `while(1)` but continues calling `IWDG_Refresh(&hiwdg)`. If the loop stalls, the independent watchdog expires and triggers a hardware reset. The test in [`test_gap3_iwdg_config.c`](https://github.com/NawfalMotii79/PLFM_RADAR/blob/main/test_gap3_iwdg_config.c) verifies this refresh occurs within the timeout window.

### Can the GPIO pin assignments change without breaking safety functions?

Yes, provided the unit tests are re-run. The emergency stop test uses `assert_gpio_write` to confirm that `GPIO_PIN_6` on `GPIOD` receives the reset command. Changing [`main.h`](https://github.com/NawfalMotii79/PLFM_RADAR/blob/main/main.h) definitions without updating test expectations causes explicit test failure rather than silent safety degradation.

### What synthesizer initialization follows power-up in this design?

After `EN_DIS_RFPA_VDD_Pin` asserts and settles, the firmware initializes `ADF4382A_Manager` instances for the transmit and receive PLLs. The `ADF4382A_SetOutputPower()` function configures drive levels before the PA gate control is released, ensuring no unmodulated carrier reaches the output stage during startup.