老農最近搞基于STM32F407的IAP升級固件升級功能，遇到了這樣一個問題：IAP引導程序和APP程序都是基于STM32CUBEMX的程序模板生成，單獨調試運行APP功能也都正常，但是只要采用IAP方式將APP程序的bin文件燒寫到程序存儲區，再跳轉到APP的地址運行就死掉了。

這個問題困擾了老農挺長時間，后來才發現問題所在：那就是STM32系列的單片機一旦完成PLL時鐘設置后，是不能再次配置的。

本例中IAP引導程序首先對PLL進行了成功配置，當跳轉到APP程序運行后，APP程序初始化部分又對PLL進行了一次配置，結果配置失敗，因為程序是基于STM32CUBEMX的模板，配置失敗后調用模板的Error_Handler()函數，該函數原型如下：

/**
  * @brief  This function is executed in case of error occurrence.
  * @retval None
  */
void Error_Handler(void)
{
  /* USER CODE BEGIN Error_Handler_Debug */
  /* User can add his own implementation to report the HAL error return state */
  __disable_irq();
  while (1)
  {
  }
  /* USER CODE END Error_Handler_Debug */
}

可以看到，函數內部會先禁止中斷，然后就進入死循環。這就是為什么程序每次跳轉到APP后死掉的原因。

搞清楚了問題所在，就有針對性的解決方法：一是偷懶的方法，將Error_Handler()函數的內部功能全部屏蔽，這樣即使PLL配置出錯，也能跳過去，但是必須要保證IAP引導程序和APP程序的時鐘配置完全一致，否則還是會出問題。二是想辦法重新配置PLL，這樣即使IAP引導程序和APP程序的時鐘配置不一致，程序也能順利運行。

要想重新配置STM32的PLL，通過查閱相關資料，發現STM32的PLL一旦使能后配置參數便不能更改，除非在下次重新啟動時再次配置相關參數。這樣就成死循環了，似乎只能采用前面說的第一種方法了。

老農不死心，繼續研究參考手冊，發現有這么一段話：

The three PLLs are disabled by hardware when entering Stop and Standby modes, or when
an HSE failure occurs when HSE or PLL (clocked by HSE) are used as system clock.

重點在第一句，在進入停止或待機模式時PLL可以由硬件禁止。這樣的話我們就可以在APP程序的時鐘初始化之前首先設置STM32進入停止或待機模式，然后再喚醒，并重新對PLL時鐘進行配置。

通過研究STM32的停止模式和待機模式，可以知道其進入和退出方式有一定差異，如下所示：

另外如果進入待機模式，退出后除備份區域和待機電路中的寄存器外，其他SRAM和寄存器內容全部丟失，程序將按照復位后的方式重新執行，這個并不是我們的初衷。如果每次喚醒都相當于重啟，那我們的程序就進入死循環了。

老農結合自己的實際硬件，正好在某個管腳上有一個外部I2C設備輸入方波可以用來做為喚醒源，選用停止模式。具體代碼如下：

HAL_Init();
  IIC_Init();          //外部設備初始化
  SetCLKOandSQW(0,F1Hz,S_1Hz);   //使能外部器件方波輸出
  HAL_NVIC_EnableIRQ(EXTI9_5_IRQn);  //使能方波輸入管腳中斷 
  HAL_PWR_EnterSTOPMode(PWR_MAINREGULATOR_ON, PWR_STOPENTRY_WFI);  //進入停止模式
  Stm32_Clock_Init(168,6,2,7);  //重新配置PLL并使能
  HAL_NVIC_DisableIRQ(EXTI9_5_IRQn);  //關閉方波輸入管腳中斷

為了驗證效果，將Error_Handler函數中的死循環重新打開，再次燒寫新的APP程序，這次APP能夠正常運行，這說明通過采用進入停止模式再重新配置PLL時鐘是可行的。

采用這種方法確實可以解決PLL的重配置，但是需要結合自己的硬件考慮是否具備喚醒停止模式或待機模式的能力。