Skip to content

fix(stm32f4-bootloader): disable SysTick interrupt during clock init …#496

Open
is-northfish wants to merge 1 commit into
dji-sdk:masterfrom
is-northfish:fix-freertos-systick-hardfault-stm32f4
Open

fix(stm32f4-bootloader): disable SysTick interrupt during clock init …#496
is-northfish wants to merge 1 commit into
dji-sdk:masterfrom
is-northfish:fix-freertos-systick-hardfault-stm32f4

Conversation

@is-northfish

Copy link
Copy Markdown

Description of the Bug

In the mdk_bootloader.uvprojx routine for the STM32F4 platform, the system encounters a consistent HardFault during startup on custom hardware utilizing a passive crystal oscillator.

Root Cause Analysis:

  1. HAL_Init() sets up and enables the SysTick timer and its interrupt.
  2. SystemClock_Config() blocks execution while waiting for the HSE oscillator to stabilize (RCC_WaitForHSEOSCReady()).
  3. Due to the physical startup delay of passive crystals (unlike the HSE Bypass mode on official evaluation boards, which masks this issue), the SysTick interrupt triggers before the FreeRTOS scheduler has been initialized.
  4. The ISR jumps to the FreeRTOS SysTick_Handler and calls xTaskIncrementTick(). Since the scheduler isn't running, it attempts to dereference an uninitialized pxCurrentTCB (NULL pointer), leading to a HardFault.

Proposed Fix

This PR provides a lightweight, register-level fix to resolve the race condition.
By explicitly clearing the SysTick_CTRL_TICKINT_Msk bit immediately after HAL_Init(), the SysTick interrupt is suppressed during the SystemClock_Config() blocking phase.

    /* Reset of all peripherals, Initializes the Systick. */
    HAL_Init();
  
    /* Disable SysTick interrupt to prevent early FreeRTOS tick during HSE delay */
    SysTick->CTRL &= ~SysTick_CTRL_TICKINT_Msk;
    
    /* Configure the system clock to have a system clock = 168 Mhz */
    SystemClock_Config();

…to prevent HardFault

During initialization, HAL_Init() configures and enables the SysTick interrupt.
Subsequently, SystemClock_Config() blocks while waiting for the HSE oscillator
to stabilize. On custom hardware with passive crystals, this physical delay
allows the SysTick interrupt to fire before the FreeRTOS scheduler is started.
This leads to a HardFault inside xTaskIncrementTick() due to a NULL pxCurrentTCB.

This fix clears the SysTick_CTRL_TICKINT_Msk bit immediately after HAL_Init(),
disabling the interrupt during the blocking clock configuration phase. FreeRTOS
will properly reconfigure and re-enable SysTick when the scheduler starts.
@is-northfish

Copy link
Copy Markdown
Author

Status Update:
I have communicated with the DJI PSDK R&D team via official support. They have evaluated and confirmed that this timing race condition indeed exists on custom hardware due to the physical startup delay differences.

The team plans to optimize the Bootloader clock configuration and unify the HAL timebase settings across the RTOS examples in a future release to ensure initialization stability.

I will leave this PR open as a temporary workaround reference for the community until the official fix is rolled out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant