cancel
Showing results for 
Search instead for 
Did you mean: 

Variable rolling to 255

psain.1
Associate III

I have STM32G070RBT6, a timer is set to give interrupt every 1 second, in interrupt i am incrementing a variable timer_var1 then in main file while loop i am dividing this by 10 and assigning this value to another variable TIMER_NOW.

Now when timer_var1 hits value 389(decimal) it rolls over to 255(dec).

there is nothing else in the while loop.

i am not able to figure out how is it possible.

 

code: 

volatile uint16_t timer_var1=0,TEMP,TIMER_PREV=0,TIMER_NOW=0;

  while (1)
  {


   TIMER_NOW=timer_var1/10;
//    if(TIMER_NOW>TIMER_PREV){
//    COR_Y[TIMER_NOW]=270-TEMP-TIMER_NOW*2;
//    COR_X[TIMER_NOW]=TIMER_NOW*7;
//        TIMER_PREV=TIMER_NOW;}


//   DWIN_DRAW_LINE(0x5000, COR_X,COR_Y, TIMER_NOW);

 


//   HAL_UARTEx_ReceiveToIdle_IT(&huart1, RX_BUFF_LCD, 16);


  HAL_Delay(300);


  HAL_GPIO_TogglePin(STATUS_GPIO_Port, STATUS_Pin);
    /* USER CODE END WHILE */


    /* USER CODE BEGIN 3 */
  }

 

 

In interrupt file:

/* USER CODE BEGIN PV */
extern volatile unsigned int DataPos;
extern volatile unsigned char RX_BUF[256u];
extern volatile uint16_t timer_var1;
/* USER CODE END PV */

 

void TIM1_BRK_UP_TRG_COM_IRQHandler(void)
{
  /* USER CODE BEGIN TIM1_BRK_UP_TRG_COM_IRQn 0 */
timer_var1++;
  /* USER CODE END TIM1_BRK_UP_TRG_COM_IRQn 0 */
  HAL_TIM_IRQHandler(&htim1);
  /* USER CODE BEGIN TIM1_BRK_UP_TRG_COM_IRQn 1 */


  /* USER CODE END TIM1_BRK_UP_TRG_COM_IRQn 1 */
}

 

 

snip1.pngsnip2.png

1 ACCEPTED SOLUTION

Accepted Solutions

Hello @psain.1

Maybe implement a bounds checking mechanism to ensure that you do not write beyond the bounds of the TX_BUFF_LCD array 

 if (lenght + 12 < sizeof(TX_BUFF_LCD)) {
        TX_BUFF_LCD[lenght + 12] = 0xFF;
    }
    if (lenght + 13 < sizeof(TX_BUFF_LCD)) {
        TX_BUFF_LCD[lenght + 13] = 0x00;
    }

    // Ensure that the length does not exceed the buffer size
    if (lenght + 13 < sizeof(TX_BUFF_LCD)) {
        HAL_UART_Transmit_IT(&huart1, TX_BUFF_LCD, lenght + 13);
    }

 Also, you can add a break inside the loop to prevent writing beyond the buffer size if the calculated index exceeds the buffer size.

for (int i = 0; i < lenght; i += 4) {
        if (12 + i + 3 < sizeof(TX_BUFF_LCD)) {
            TX_BUFF_LCD[12 + i] = (cor_x[i / 4] & 0xFF00) >> 8; // Higher byte
            TX_BUFF_LCD[13 + i] = cor_x[i / 4] & 0x00FF;        // Lower byte
            TX_BUFF_LCD[14 + i] = (cor_y[i / 4] & 0xFF00) >> 8; // Higher byte
            TX_BUFF_LCD[15 + i] = cor_y[i / 4] & 0x00FF;        // Lower byte
        } else {
            // Prevent buffer overflow
            break;
        }

 step through the code and maybe we'll get stuck in one of the IFs

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

11 REPLIES 11
Sarra.S
ST Employee

Hello @psain.1

In your code, timer_var1 is declared as volatile uint16_t, so it should hold values between 0 and 65535.

The fact that it's rolling back to 255, means that timer_var1 is being treated as an 8-bit variable somewhere in your code, maybe check all files where it is used, implicit conversions... 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

gbm
Lead III

My wild guess is stack overflow.

Which data items are declared at external level and which ones in the functions?

Show the declarations of all the data. Append a more complete code use "insert code sample" function of forum editor to make the code easily readable to anyone wishing to help you.

 

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice

@gbm wrote:

use "insert code sample" function of forum editor to make the code easily readable to anyone wishing to help you.


@psain.1  - see the Posting Tips for full instructions on how to do that:

https://community.st.com/t5/community-guidelines/how-to-write-your-question-to-maximize-your-chances-to-find-a/ta-p/575228

 

psain.1
Associate III

Both the files are attached, only here these variables are attached.. there was a lot of code there before this issue.

I removed it to find the cause of the problem and this is what is left.

TDK
Guru

Set a hardware watchpoint on the variable and it will break when it gets modified. Probably you have an out of bounds write somewhere, possibly to RAM_BUFF.

If you feel a post has answered your question, please click "Accept as Solution".
psain.1
Associate III

I have narrowed down the issue this is after commenting line by line and testing i found that the these lines following function are cause of the problem.. still cannot figure out why

 

void DWIN_DRAW_LINE(int ADD, uint16_t cor_x[], uint16_t cor_y[], uint16_t size){
// TX_BUFF_LCD[0]=0x5A;TX_BUFF_LCD[1]=0xA5;TX_BUFF_LCD[3]=0x82;
// TX_BUFF_LCD[4]=(ADD&0xFF00)>>8;TX_BUFF_LCD[5]=ADD&0x00FF;
// TX_BUFF_LCD[6]=0x00;TX_BUFF_LCD[7]=0x02;
uint8_t lenght = 4*size;
// TX_BUFF_LCD[8]=00;TX_BUFF_LCD[9]=size-1;TX_BUFF_LCD[10]=0xF8;TX_BUFF_LCD[11]=0x00;
//
// for (int i = 0; i < (lenght); i += 4) {
// TX_BUFF_LCD[12 + i] = (cor_x[i/4] & 0xFF00) >> 8; // Higher byte
// TX_BUFF_LCD[13 + i] = cor_x[i/4] & 0x00FF; // Lower byte
// TX_BUFF_LCD[14 + i] = (cor_y[i/4] & 0xFF00) >> 8; // Higher byte
// TX_BUFF_LCD[15 + i] = cor_y[i/4] & 0x00FF; // Lower byte
// }
TX_BUFF_LCD[2]=lenght+11;
TX_BUFF_LCD[lenght+12]=0xFF;TX_BUFF_LCD[lenght+13]=0x00;
// HAL_UART_Transmit_IT(&huart1, TX_BUFF_LCD, (lenght+13));
}

 

the lines which are not commented are the problem

 

if i remove 

1. TX_BUFF_LCD[2]=lenght+11;  no change

2. TX_BUFF_LCD[lenght+12]=0xFF; timer_var1 rolls to 134

3. TX_BUFF_LCD[lenght+13]=0x00; timer_var1 rolls over to 511

 

if i change the type of TX_BUFF_LCD[] to uint16_t from uint8_t.. the the problem the issue goes away.. but that will make my entire code useless

 

Also i have removed unused code from originally uploaded main.c 

psain.1
Associate III

I commented everything including RAM_BUFF usage

Hello @psain.1

Maybe implement a bounds checking mechanism to ensure that you do not write beyond the bounds of the TX_BUFF_LCD array 

 if (lenght + 12 < sizeof(TX_BUFF_LCD)) {
        TX_BUFF_LCD[lenght + 12] = 0xFF;
    }
    if (lenght + 13 < sizeof(TX_BUFF_LCD)) {
        TX_BUFF_LCD[lenght + 13] = 0x00;
    }

    // Ensure that the length does not exceed the buffer size
    if (lenght + 13 < sizeof(TX_BUFF_LCD)) {
        HAL_UART_Transmit_IT(&huart1, TX_BUFF_LCD, lenght + 13);
    }

 Also, you can add a break inside the loop to prevent writing beyond the buffer size if the calculated index exceeds the buffer size.

for (int i = 0; i < lenght; i += 4) {
        if (12 + i + 3 < sizeof(TX_BUFF_LCD)) {
            TX_BUFF_LCD[12 + i] = (cor_x[i / 4] & 0xFF00) >> 8; // Higher byte
            TX_BUFF_LCD[13 + i] = cor_x[i / 4] & 0x00FF;        // Lower byte
            TX_BUFF_LCD[14 + i] = (cor_y[i / 4] & 0xFF00) >> 8; // Higher byte
            TX_BUFF_LCD[15 + i] = cor_y[i / 4] & 0x00FF;        // Lower byte
        } else {
            // Prevent buffer overflow
            break;
        }

 step through the code and maybe we'll get stuck in one of the IFs

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Value of timer_var1 above approx. 330 will result in overwriting some of the variables, presumably timer_var is overwritten. Ther is no check for range of 'size' var in DRAW_LINE, and TX_BUFF_LCD has a size of 150 only.

BTW. Do not use all-uppercase names for variables and routines.

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice