【微控制器重啟】MSP430重啟/頻繁重啟/跑飛 原因分析
阿新 • • 發佈:2019-01-05
1、堆疊溢位導致頻繁重啟:
案例1:
concern_tower_num為從鐵電內讀取的資料,因為鐵電沒有初始化,所以concern_tower_num的值很大
下面的程式一直迴圈到鐵電內concern_tower_num所在位置的值,所以超過了option內所設定的stack的最大容量導致堆疊溢位,重啟。
for(int i=0;i
{
data[m]=crane_tower[i].crane_x;
m++;
data[m]=crane_tower[i].crane_y;
m++;
data[m]=crane_tower[i].front_arm_length;
m++;
} 2012.4.20 UESTC 2、陣列越界: 定義了一個29位元組長度的陣列: char back_info[29]={0}; 結果給其填充50個位元組的內容 memcpy( back_info+19,send_back_data,data_len); ,現象是堆疊沒有溢位,機器重啟。 2012.4.24 UESTC 問 程式總是莫名其妙的重新啟動?
已經檢查了堆疊沒有溢位,WDT依然還是HOLD狀態
哪位高手指點一下,還有哪種可能性? 答 1 :
先看IFG1.0位狀態,看是什麼原因導致復位
答 2:
您測量一下復位腳上的波形,看是否是硬體復位。
答 3:
你的工作環境??是不是干擾問題?
是不是指標弄飛了?? 答 4: 外部有看門狗嗎?有的話要先關掉。 答 5: 謝謝以上各位的回答:
我的具體情況是原來程式是用查詢方式,已經通過測試,沒有這個問題
而現在需要新增部分功能,為此把查詢方式改為了中斷方式(新功能還未新增),
現在已經檢查過IFG1.0位0,不是內部看門狗導致復位
外部無看門狗,也無明顯干擾源
硬體復位可能性也不大,不過這個可以再測一下!
有可能是指標弄飛等程式錯誤,但是這種內部程式錯誤會導致系統復位嗎? 答 6: 錯誤寫FLASH也能復位,程式超出,復位向量錯誤等也可能導致復位。 答 7 :
可能是復位電路問題!
答 8:
經測試,不是外部復位電路的問題!
現在問題應該在中斷子程式對主函式造成了不確定的影響上,
但是目前仍無法定位問題在哪?
鬱悶ing!!! 答 9: 是無法進入中斷嗎還是其他的原因,能具體說的詳細些嗎。 答 10: 呵呵,我的問題是430出現不確定的復位,有時執行幾分鐘就復位,有時能到幾十分鐘
而在這之前,我的程式是用的查詢方式處理外部事務,一直執行正常,沒有這個問題
現在改為中斷來處理外部事務,就出現了莫名的復位問題
中斷是能正常進入的!!
通過幾天的排查,現在問題應該在中斷子程式對主函式造成了不確定的影響,
從而導致了系統復位。但無法定位問題所在! 答 11: 檢查一下資料指標吧,是否超出記憶體範圍,看現象可能是這方面的影響 答 12 :
程式發出來看看,不然幹說也是查不出來
答 13:
一箇中斷一箇中斷使能,一個一個排查。多試幾次就是了。把問題分塊一個一個來。看哪個出的問題
這個跟微控制器支援的斷點個數也是有關的。如果只支援一個斷點,你設定了2個,然後復位的話就容易跑到Cstart而不是Main。另外要注意IAR
run to Main的複選框你勾上沒?
案例二:跑飛
void send_basic_data_to_dis_part()
{
char
basic_data_buf[60]={0};
char
frame_head[2]={0xFE,0xFB},frame_end[2]={0xFE,0xFA};
char
frame_len[1]={0x45},frame_type[1]={0x40};
char
bCRC[2]={0,0};
char
tower_num[1]={0x08};
unsigned int addr=0;
addr=split_joint_hex_data(
basic_data_buf,addr,frame_head,2);
addr=split_joint_hex_data(
basic_data_buf,addr,frame_len,1);
addr=split_joint_hex_data(
basic_data_buf,addr,frame_type,1);
addr=split_joint_hex_data(
basic_data_buf,addr,tower_num,1);
for(uint8 i=0;i
{
addr=split_joint_hex_data(
basic_data_buf,addr,(char*)(&crane_tower[i].lcd_x),2);
addr=split_joint_hex_data(
basic_data_buf,addr,(char*)(&crane_tower[i].lcd_y),2);
addr=split_joint_hex_data(
basic_data_buf,addr,(char*)(&crane_tower[i].dis_fore_r),2);
addr=split_joint_hex_data(
basic_data_buf,addr,(char*)(&crane_tower[i].dis_back_r),2);
}
CRC16(bCRC,basic_data_buf+2, addr-2);
//資料CRC校驗
addr=split_joint_hex_data(
basic_data_buf,addr,bCRC,2);
addr=split_joint_hex_data(
basic_data_buf,addr,frame_end,2);
UART2_Send_Buf(basic_data_buf,addr);
}
//basic_data_buf[60] 陣列所開闢的長度為60,但是在下面從basic_data_buf首地址起填裝資料的過程當中,填寫的資料長度超過了60,陣列越界,破壞了棧內保持的進入send_basic_data_to_dis_part()函式之前儲存的現場資料,結果跳出該函式呼叫,要執行下步的時候,由於SP內的值已經被修改,導致程式跑飛。(這種情況症狀往往表現為:進入某個函式內正常,在跳出的時候就跑飛,多為在函式內SP的指標被修改)
跑飛三: 程式中有 mallco()動態申請記憶體空間,卻沒有相應的釋放,結果記憶體消耗完畢,程式跑飛。
{
data[m]=crane_tower[i].crane_x;
m++;
data[m]=crane_tower[i].crane_y;
m++;
data[m]=crane_tower[i].front_arm_length;
m++;
} 2012.4.20 UESTC 2、陣列越界: 定義了一個29位元組長度的陣列: char back_info[29]={0}; 結果給其填充50個位元組的內容 memcpy( back_info+19,send_back_data,data_len); ,現象是堆疊沒有溢位,機器重啟。 2012.4.24 UESTC 問 程式總是莫名其妙的重新啟動?
已經檢查了堆疊沒有溢位,WDT依然還是HOLD狀態
哪位高手指點一下,還有哪種可能性? 答 1
是不是指標弄飛了?? 答 4: 外部有看門狗嗎?有的話要先關掉。 答 5: 謝謝以上各位的回答:
我的具體情況是原來程式是用查詢方式,已經通過測試,沒有這個問題
而現在需要新增部分功能,為此把查詢方式改為了中斷方式(新功能還未新增),
現在已經檢查過IFG1.0位0,不是內部看門狗導致復位
外部無看門狗,也無明顯干擾源
硬體復位可能性也不大,不過這個可以再測一下!
有可能是指標弄飛等程式錯誤,但是這種內部程式錯誤會導致系統復位嗎? 答 6: 錯誤寫FLASH也能復位,程式超出,復位向量錯誤等也可能導致復位。 答 7
現在問題應該在中斷子程式對主函式造成了不確定的影響上,
但是目前仍無法定位問題在哪?
鬱悶ing!!! 答 9: 是無法進入中斷嗎還是其他的原因,能具體說的詳細些嗎。 答 10: 呵呵,我的問題是430出現不確定的復位,有時執行幾分鐘就復位,有時能到幾十分鐘
而在這之前,我的程式是用的查詢方式處理外部事務,一直執行正常,沒有這個問題
現在改為中斷來處理外部事務,就出現了莫名的復位問題
中斷是能正常進入的!!
通過幾天的排查,現在問題應該在中斷子程式對主函式造成了不確定的影響,
從而導致了系統復位。但無法定位問題所在! 答 11: 檢查一下資料指標吧,是否超出記憶體範圍,看現象可能是這方面的影響 答 12
跑飛三: 程式中有 mallco()動態申請記憶體空間,卻沒有相應的釋放,結果記憶體消耗完畢,程式跑飛。