STM32在使用中，因為一般沒有其他異常拋出，所以拋出異常一般都是HardFault_Handler.
導致產生該現象的原因有一下幾點：
(1)數組越界操作；
(2)內存溢出，訪問越界；
(3)堆棧溢出，程序跑飛；
(4)中斷處理錯誤；
一，數組越界
毋庸置疑，程序中使用了靜態數組，而在動態傳參時數組賦值溢出。或者動態分配內存太小，導致程序異常。
二，內存溢出
重點檢查RAM區域，程序編譯后執行的RAM數據量大小為多少是否可能越界。一般不要設置到極致的情況，程序中的一些動態數組傳參時會導致異常。
計算 RW-data+ZI-data 為需要存儲在RAM區域的變量等。
檢查程序編譯后的.MAP文件。
對應手冊，或者編譯器查找到對應RAM存儲空間區域。找到該區域分析，並對應。
例入 此芯片的RAM區域為0X20000000的48K的存儲空間，檢查這些變量，特別是全局變量的分配。
RAM區域內存分配不足時，檢查某些變量是否可以申請為存在代碼區域。
本設計中可以看到，由於申請了幾個大的靜態數組，RAM區域已經使用到了b790 離 C000的48K 內存已十分接近。
在這種問題下，尤其需要注意：
使用Printf，vsprintf，sprintf 格式化數據導致的內存問題，這些函數使用的內存空間較大，猜測是由於，該函數采用的拷貝數組的形式轉換，內存耗費劇烈。
使用操作系統的若為 設置鈎子函數拋出異常，則也會產生該問題。配置操作系統所用空間，包含消息量，消息隊列，郵箱，任務堆棧等。
三，堆棧溢出
這在使用操作中問題尤其嚴重，在操作系統中，任務的變量均分配放置在任務所申請的堆棧空間中，例如FreeRTOS的
xTaskCreate task. h 創建新的任務並添加到任務隊列中，准備運行 Parameters: pvTaskCode 指向任務的入口函數. 任務必須執行並且永不返回 (即：無限循環). pcName 描述任務的名字。主要便於調試。最大長度由configMAX_TASK_NAME_LEN.定義 usStackDepth 指定任務堆棧的大小 ，堆棧能保護變量的數目- 不是字節數. 例如，如果堆棧為16位寬度，usStackDepth定義為 100, 200 字節，這些將分配給堆棧。堆棧嵌套深度（堆棧寬度）不能超多最大值——包含了size_t類型的變量 pvParameters 指針用於作為一個參數傳向創建的任務 uxPriority 任務運行時的優先級( 0 : 優先級最低) pvCreatedTask 用於傳遞一個處理——引用創建的任務 返回: pdPASS 是如果任務成功創建並且添加到就緒列中，另外錯誤代碼在projdefs. H文件定義
所創建的任務需要指定堆棧大小，那么堆棧申請不足，則會出現異常，針對該問題可啟動系統的鈎子函數HOOK函數，拋出該異常。
四，中斷處理異常
程序中開啟了某些中斷，例如USART,TIMER,RTC等。
但在程序執行中，滿足中斷條件，但並未能查找到該部分對應的中斷服務函數，則會拋出該異常。