Troubleshooting the cause of the crash when STM32 serial port dam receives 253 bytes

I made a plan a few days ago , It's about STM32 adopt M5311 Connect MQTT How to communicate with the server . After all parameters are tested , adopt MQTT The server sent a 300bytes Device parameter configuration instructions , As a result, it crashed directly . After many tests , The problem phenomenon is specifically determined as MQTT Server send 253 Bytes can be normal , Send greater than 254 Byte above STM32 Must crash .

To locate the cause of the problem , So separate tests . Test first STM32 Serial port communication , A serial port DMA To receive the 500 Bytes are also normal . Then test it separately M5311, Serial port sent 300 Bytes are also normal . It's depressing , It's OK for both of them to be alone , Why did they crash together .

1. First, it is suspected that the serial port receiving cache is not enough , So I checked , yes 1000 byte , More than enough ！
2. It is doubted that it is serial port ORE Overflow causes crash , As a result, the program tracked for a long time , That's all right. , It is wronged .
3. Check the serial port waveform , Find out STM32 It seems that the baud rate is a little lower , But they can recognize each other , It should be within the error range . Adjust the baud rate a little , The problem is still loud .
4. Doubt again DMA error , Program tracking inspection , That's right .
5. There is no way out , Then trace the serial port interrupt function . In all if–else Print statements are added in , All the way down , It is found that the serial port interrupt processing is also very perfect . It is also wronged .
6. After the serial port interrupt processing is completed , Is the server instruction parsing function , Finally check it . Actually, the problem is caused by it ！ After receiving serial port data , It first moves the data to another cache array , Then open the DMA Receive the next batch of data . The problem lies in moving , Used for loop , And the loop variable used is uint8_t, But the judgment condition for exiting the cycle is beyond 255 Of , That is, it inadvertently becomes a dead cycle . So it crashed .

/********************************************************************  Letter   Count   name ：void Data_Transfer_To_Cache(void)  function ： Data is cached to another array , Then open it again immediately DMA Receive   Parameters ： nothing   Return value ： nothing  ***********************************************************************/	
uint8_t Data_Transfer_To_Cache(void)
{
    
	// First, transfer it immediately , Then open the DMA receive , Then judge 
	uint8_t data_err = 0;
	Clear_Tmp_Sz();
	if(UART3_Rx_len<TP_LENGTH)// Prevent the array from accidentally crossing the bounds 
	{
    
		for(uint16_t i=0;i<UART3_Rx_len;i++)
		{
    
			tmp_rx_sz[i] = UART3_Rx_buffer[i];
		}
		tmp_i = UART3_Rx_len;
	}
	else	
	{
    
		data_err = 1;
	}
	DMA_UART3_Start();// Clear receive cache , open DMA Continue to receive 
	
// printf("\r\n%s\r\n",tmp_rx_sz);
	if(data_err)
	{
    
		printf(" Data out of cache ！\r\n");
		return 0;
	}
	else
	{
    
		return 1;	
	}
}

This function is responsible for moving bricks , Among them for(uint8_t i=0; i<UART3_Rx_len; i++) loop , stay UART3_Rx_len Greater than 255 When , It's a cycle . This is directly from the previous project copy Over here , I didn't consider this at all i There will be problems .
It took 2 Days time , I checked everything from hardware to software , Even the serial port waveform has been checked , A small problem wastes a lot of time , It's a lesson . I hope you can take a warning , Later transplantation copy Code carefully , Or simply write code for this loop ,i Variables are always used uint32_t type , It's impossible to get out .