Skip to main content
psain.1
Associate III
September 17, 2024
Solved

Variable rolling to 255

  • September 17, 2024
  • 11 replies
  • 3736 views

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

This topic has been closed for replies.
Best answer by Sarra.S

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

11 replies

ST Employee
September 17, 2024

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
Super User
September 17, 2024

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
Andrew Neil
Super User
September 17, 2024

@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

 

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
psain.1
psain.1Author
Associate III
September 17, 2024

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
September 17, 2024

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
psain.1Author
Associate III
September 17, 2024

I commented everything including RAM_BUFF usage

psain.1
psain.1Author
Associate III
September 17, 2024

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 

Sarra.SBest answer
ST Employee
September 17, 2024

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.
psain.1
psain.1Author
Associate III
September 17, 2024

Yes it was the size of TX_BUFF_LCD... which was overflown and writing to memory space where timer_var1 might be defined

i changed the size of TX_BUFF_LCD and problem solved completely