中文字幕 另类精品,亚洲欧美一区二区蜜桃,日本在线精品视频免费,孩交精品乱子片免费

<sup id="3hn2b"></sup>
  • 

      <sub id="3hn2b"><ol id="3hn2b"></ol></sub><legend id="3hn2b"></legend>
        

        2. <xmp id="3hn2b"></xmp>
        3. 
	
	
        
		
			
		
        
    
    	
        
  		
        
		    
        
		      
		      
		      
		    
        
  		
        
  		
        
	
        


	


        
		
        
		            
            
        		
        
		
        







        


        
	
	
        
		
        新聞中心
        
	
        
	
        
	
        EEPW首頁 
	 > 嵌入式系統(tǒng) > 設計應用 > MSP430重啟/頻繁重啟/跑飛 原因分析
        
    
        

        

        


	
	
	

        
	
        
		
        
			
        MSP430重啟/頻繁重啟/跑飛 原因分析
        
						
        
				作者：
				時間：2016-11-24
				來源：網絡
				
				
				
				
				收藏
			
        

			
        
				
				
			
        

			
        
			
			
        
			
			
        
				
				
			
        
                
			1、堆棧溢出導致頻繁重啟：
        案例1：
        concern_tower_num為從鐵電內讀取的數(shù)據，因為鐵電沒有初始化，所以concern_tower_num的值很大
        下面的程序一直循環(huán)到鐵電內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、數(shù)組越界：
        定義了一個29字節(jié)長度的數(shù)組： char back_info[29]={0};
        結果給其填充50個字節(jié)的內容 memcpy( back_info+19,send_back_data,data_len); ，現(xiàn)象是堆棧沒有溢出，機器重啟。
        2012.4.24 UESTC
        問
        MSP430F147程序總是莫名其妙的重新啟動？
        已經檢查了堆棧沒有溢出，WDT依然還是HOLD狀態(tài)
        哪位高手指點一下，還有哪種可能性？
        答 1:
        先看IFG1.0位狀態(tài)，看是什么原因導致復位
        答 2:
        您測量一下復位腳上的波形，看是否是硬件復位。
        答 3:
        你的工作環(huán)境？？是不是干擾問題？
        是不是指針弄飛了？？
        答 4:
        外部有看門狗嗎？有的話要先關掉。
        答 5:
        謝謝以上各位的回答：
        我的具體情況是原來程序是用查詢方式，已經通過測試，沒有這個問題
        而現(xiàn)在需要添加部分功能，為此把查詢方式改為了中斷方式（新功能還未添加），

        現(xiàn)在已經檢查過IFG1.0位0，不是內部看門狗導致復位
        外部無看門狗，也無明顯干擾源
        硬件復位可能性也不大，不過這個可以再測一下！

        有可能是指針弄飛等程序錯誤，但是這種內部程序錯誤會導致系統(tǒng)復位嗎？
        答 6:
        錯誤寫FLASH也能復位,程序超出,復位向量錯誤等也可能導致復位。
        答 7:
        可能是復位電路問題！
        答 8:
        經測試，不是外部復位電路的問題！
        現(xiàn)在問題應該在中斷子程序對主函數(shù)造成了不確定的影響上，
        但是目前仍無法定位問題在哪？
        郁悶ing?。?！
        答 9:
        是無法進入中斷嗎還是其他的原因，能具體說的詳細些嗎。
        答 10:
        呵呵，我的問題是430出現(xiàn)不確定的復位，有時運行幾分鐘就復位，有時能到幾十分鐘
        而在這之前，我的程序是用的查詢方式處理外部事務，一直運行正常，沒有這個問題
        現(xiàn)在改為中斷來處理外部事務，就出現(xiàn)了莫名的復位問題

        中斷是能正常進入的！！

        通過幾天的排查，現(xiàn)在問題應該在中斷子程序對主函數(shù)造成了不確定的影響,
        從而導致了系統(tǒng)復位。但無法定位問題所在！
        答 11:
        檢查一下數(shù)據指針吧，是否超出內存范圍，看現(xiàn)象可能是這方面的影響
        答 12:
        程序發(fā)出來看看,不然干說也是查不出來
        答 13:
        一個中斷一個中斷使能，一個一個排查。多試幾次就是了。把問題分塊一個一個來。看哪個出的問題
        這個跟單片機支持的斷點個數(shù)也是有關的。如果只支持一個斷點，你設置了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);                 //數(shù)據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]數(shù)組所開辟的長度為60，但是在下面從basic_data_buf首地址起填裝數(shù)據的過程當中，填寫的數(shù)據長度超過了60，數(shù)組越界，破壞了棧內保持的進入send_basic_data_to_dis_part(）函數(shù)之前保存的現(xiàn)場數(shù)據，結果跳出該函數(shù)調用，要執(zhí)行下步的時候，由于SP內的值已經被修改，導致程序跑飛。（這種情況癥狀往往表現(xiàn)為：進入某個函數(shù)內正常，在跳出的時候就跑飛，多為在函數(shù)內SP的指針被修改）

        
				
            
                
			
							
        
                
			              
              
            
        
		
        
		
        
		
        
		
        
		
        
			
          
				
        • 
					
					
			  	
          • 
			  	
        • 
					
					
			  	
          • 
			  	
        • 
					
					
			  	
          • 
				
        • 
					
					
				
          • 
				
        • 
					
					
				
          • 
			
        
			
        
		
        
		
		
        
		
        
			
			
		
        
        
		
        
			
        關鍵詞：
            			            MSP430頻繁重啟跑
                        
            
        
            
			
        
		
        	
		

	

        
	
	
        
		
        
			
        評論
        					
		
        
		
        
			
        
			
				
        
					
					
        
						
                        
					
        
				
        
                		
						
						
			
        
		
        
		
        
		
        
            
			
            
		
        
	
        
	
        
	
        
		
		

        


	
        
	
        
		
		
	
        


    
        
        
        技術專區(qū)
        
      
        
      
        
			
      
         
       

        

   











        
	
        
	    關閉