Record a stm8l program running out of control

The project uses stm8l051f3 as the master control and CC2500 for data reception, not sending.

The phenomenon of running away is that it can run at the beginning, but after a period of unknown length of time, which may be 3 minutes or 30 minutes, the indicator light no longer flashes and the interrupt button microcontroller does not respond.

After connecting to the debugger, I found that the program ran to a very large address, which exceeded the internal flash space of the MCU. It can be determined that the program ran away.

The experience is:

If the program runs out of control, check whether all conditional statements have been processed.

The program is running out of control, check for memory overflow.

After checking for a long time, I found out that it was caused by memory overflow.

Because the data sent by the sender is fixed at 32 bytes, only a 32-byte buffer is opened on the receiving end to read the received data.

/***********************************************************************************  

* @brief GDO2 interrupt handling function  

* @param None

* @retval None

****************************************************************Author:Liming**/

void GDO2_Int(void)

{

    uint8_t temp;

    unsigned char RecvBuffer[0x20]={0}; //Open a 32-byte buffer

    unsigned char RecvLength;

    if(EXTI_GetITStatus(EXTI_IT_Pin6) != RESET)

    {

        EXTI_ClearITPendingBit(EXTI_IT_Pin6);

        DelayNms(1); //Wait for receiving to complete

        RecvLength = CC2500Recv(RecvBuffer); //Get the length of the received data

        temp = ProPacketCheck(RecvBuffer,RecvLength,0x0001,0x0003); //Data integrity check

        if((temp == 0x04)||(temp==0xff)) // Local and broadcast information need to be processed

        {            

　　　　　　  //data processing

            CC2500SetState(CC2500_STATUS_POWERDOWN_LEVEL2);            

        }

        else

            CC2500SetState(CC2500_STATUS_RECEIVE);

    }

}

//Receive data

unsigned char CC2500Recv(unsigned char *Buffer,unsigned char Mode)

{

  unsigned char Result=0x00,Status=0x00;

  switch(CC2500State)

  {

  case 0x00:

  case 0x01:

    if(CC2500State) Delayms(0x07);

    else Delayus(0x30);

    Status=CC2500SpiReadStatus(RXBYTES);

    if(Status&0x80) //If the data length exceeds 64 bytes

    {

      CC2500SpiReadBuffer(FIFO,Buffer,0x40); //Read 64 bytes

      Result=0x40;

    }

    else if(Status&0x7F)

    {

      CC2500SpiReadBuffer(FIFO,Buffer,Status&0x7F); //Read received data

      Result=Status&0x7F;

    }

    CC2500SetState(Mode);

    break;

  }

  return Result; //Return the length of the data read

}

However, due to interference from wireless signals, CC2500 may receive data larger than 32 bytes (although this is not required by this system).

As a result, when the data is retrieved from cc2500, the length of the buffer stored exceeds the allocated buffer space.

Solution 1: Since we know it is 32 bytes of data, we can

    The CC2500Recv receive function only receives 32 bytes.

    if(Status&0x80) //If the data length exceeds 64 bytes

    {

      CC2500SpiReadBuffer(FIFO,Buffer,0x20); //Read 32 bytes

      Result=0x20;

    }

    else if(Status&0x7F)

    {

      CC2500SpiReadBuffer(FIFO,Buffer,0x20); //Read received data

      Result=0x20;

    }

Solution 2:

The GDO2_Int function allocates 64 bytes of space so that even if the maximum amount of data is received, the buffer space will not be exceeded.

unsigned char RecvBuffer[0x40]={0}; //Open a 64-byte buffer

With this experience of dealing with program crashes, it is once again confirmed that most program crashes are caused by memory overflow.