keil defined variable changed_ Array out of bounds

keil defined variable changed_ Array out of bounds
✍ summary
   in the process of debugging CANFD(MCP2517 driver) in STM32 program, I found that the array I defined was assigned a value for no reason. Even if I assigned an initial value, it would be changed.
   the compilation environment is Keil5. The reason is analyzed by viewing the variable address.

Variable changed
   the array defined by yourself is SensorValue[7], and each element is assigned an initial value of 0x0000.

uint16_t SensorValue[7]={0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000};//Defined array

   there is no assignment to the SensorValue[] array in the program, but the value of the array is debugged during the program running, as shown in the following figure:

The first element of the array SensorValue[0] was found to have been changed.

Analyze the cause by Keil viewing the variable address
   open it with notepad++ in keil's project map file (where you can see the size, address and other information of all variables). Searching for the wrong array name SensorValue, we found that the address of the array is 0x24000208 and the size is 14 bytes.

Because the first element SensorValue[0] of the array is changed, that is, the data at the first address of the array is changed, so we view the data can3 of an address before the first address 0x24000208 of the array_ Whether the spireceivebuffer operates beyond the bounds to the data of the SensorValue array. Find can3 in the program_ Spireceivebuffer definition:

#define SPI_DEFAULT_BUFFER_LENGTH 96
uint8_t CAN3_spiTransmitBuffer[SPI_DEFAULT_BUFFER_LENGTH];

The array is 96 bytes in size The map file is indeed 96 bytes.

Then press Ctrl+F in keil to search all can3_ Spitransmitbuffer (this is not necessary for debugging inexplicable bugs) discovery (just look at the two sentences of the following program)

int8_t CAN3_DRV_CANFDSPI_WriteByteArray(CANFDSPI_MODULE_ID index, uint16_t address,
        uint8_t *txd, uint16_t nBytes)
{
    uint16_t CAN3_i;
   uint16_t spiTransferSize = nBytes + 2;//Just look here!!!!!!
    int8_t spiTransferError = 0;

    // Compose command
    CAN3_spiTransmitBuffer[0] = (uint8_t) ((cINSTRUCTION_WRITE << 4) + ((address >> 8) & 0xF));
    CAN3_spiTransmitBuffer[1] = (uint8_t) (address & 0xFF);

    // Add data
    for (CAN3_i = 2; CAN3_i < spiTransferSize; CAN3_i++) {//Just look here!!!!!
        CAN3_spiTransmitBuffer[CAN3_i] = txd[CAN3_i - 2];
    }

    spiTransferError = CAN3_DRV_SPI_TransferData(index, CAN3_spiTransmitBuffer, CAN3_spiReceiveBuffer, spiTransferSize);

    return spiTransferError;
}

From the first place of the program

uint16_t spiTransferSize = nBytes + 2;//Just look here!!!!!!

The value of spiTransferSize found in is spiTransferSize = 96 (nbytes) +2, that is, spiTransferSize =98. Observe that the Debug window is really 98:

Look at the second part of the procedure

for (CAN3_i = 2; CAN3_i < spiTransferSize; CAN3_i++) {//Just look here!!!!!
        CAN3_spiTransmitBuffer[CAN3_i] = txd[CAN3_i - 2];
    }

For can3 with a size of 96 bytes_ The spitransmitbuffer array is assigned 96 times. The for loop starts from 2 to spiTransferSize. Although the spiTransferSize-2 is executed, that is, 96 times, can3 appears_ Spitransmitbuffer[96], CAN3_spiTransmitBuffer[97], while can3_ The size of the spitransmitbuffer array is 96 bytes, and the maximum array element is CAN3_spiTransmitBuffer[95], so the array is out of range by 2 bytes. In View can3 in the map file_ The first address of the spitransmitbuffer is offset by 96 bytes to the address of the next variable SensorValue

But we're very interested in CAN3_spiTransmitBuffer[96],CAN3_spiTransmitBuffer[97] is also assigned a value. These two data have exceeded can3_ The spitransmitbuffer has jurisdiction, so it occupies the first two bytes of the SensorValue array. Therefore, we do not assign values to the SensorValue array, but the values of internal elements change:

Summary: array out of bounds will cause the data of the last bit of memory occupied by the array to change, so we should avoid this situation when operating the array at ordinary times.

If there is any mistake, welcome to instruct!!!

Tags: stm32 Programming

Posted by sivarts on Mon, 30 May 2022 06:58:35 +0530