STM32移植freeModbus觸發(fā)HardFault_Handler

移植freeModbus，根據(jù)文檔的提示看似非常的簡單，在實際過程中還是遇到不少問題的，其中一個問題就是在移植freeModbus之后系統(tǒng)進(jìn)入硬件HardFault_Handler。
freeModbus需要開啟一個定時器用于通信超時處理
調(diào)試定時器時發(fā)現(xiàn)定時沒有啟動，原來STM32CubeMx配置后，需要手動調(diào)用HAL_TIM_Base_Start_IT，否則定時器沒有啟動
關(guān)于定時器的配置可以看下這篇文章
“HAL庫 CubeMX 配置 高級定時器 TIM1 詳解”
但是開啟定時器后，系統(tǒng)在啟動定時器時即進(jìn)入HardFault_Handler，后續(xù)的代碼都沒有再執(zhí)行。
經(jīng)過各種分析，也是一籌莫展。
后來把定時器中斷回調(diào)函數(shù)中調(diào)用的prvvTIMERExpiredISR屏蔽后，系統(tǒng)正常運(yùn)行
為什么調(diào)用prvvTIMERExpiredISR會導(dǎo)致系統(tǒng)硬件異常呢？
HardFault_Handler的錯誤原因可能是
中斷沖突STM32 的定時器中斷優(yōu)先級可能與其他中斷（如 UART 中斷或 FreeRTOS 的 Systick 中斷）沖突，導(dǎo)致異常。
非法指針操作，確保定時器超時回調(diào)函數(shù)調(diào)用時，相關(guān)資源已經(jīng)正確分配。
堆棧溢出，如果定時器中斷回調(diào)函數(shù)執(zhí)行的代碼較多（例如調(diào)用了復(fù)雜的 Modbus 函數(shù)），可能會導(dǎo)致堆棧溢出，從而觸發(fā) HardFault。
后來經(jīng)過分析
是我把HAL_TIM_Base_Start_IT放在的main開始之前的初始化位置
而調(diào)用HAL_TIM_Base_Start_IT之后系統(tǒng)即觸發(fā)定時器中斷
中斷中調(diào)用prvvTIMERExpiredISR
而prvvTIMERExpiredISR存在指針函數(shù)的賦值和調(diào)用
從而導(dǎo)致空指針存在的情況
所以
HAL_TIM_Base_Start_IT需要在eMBInit 或 eMBEnable 之后調(diào)用。
基于此，我認(rèn)為還是freemodbus防出錯機(jī)制不夠健全。
官方有必要增加一個啟動定時器的移植。