How to pass a variable read in an interruption to main()

[amelendez]

Posted on June 14, 2017 at 15:14

I'm reading a serial ADC from an interruption (24 bits)

I need to pass its read value to the main()

I have defined in /* USER CODE BEGIN PV */ a volatile variable uint32_t  xxxxx

The xxxxx variable is right inside the interruption routine but it becomes 0x01FFFFFE when called in main()

How can I pass the xxxxx variable from       void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)     to      main()?

[Tesla DeLorean]

Posted on June 14, 2017 at 15:18

A global variable should be visible in main()

You might want another flag to indicate the presence of new data if that can't be inferred from the data itself.

[amelendez]

Posted on June 14, 2017 at 16:27

I did as it follows

/* USER CODE BEGIN PV */

uint32_t show;volatile uint32_t measure;/* USER CODE END PV */

int main(void) {

   HAL_Init();

   SystemClock_Config();    MX_GPIO_Init();    while (1)   {       show = measure;    }}

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)

{    uint8_t i;    if(GPIO_Pin== GPIO_PIN_3) {       HAL_GPIO_WritePin(GPIOA, GPIO_PIN_6, GPIO_PIN_RESET);       measure = 0;       for (i=0; i<24;i++) {          HAL_GPIO_WritePin(GPIOA, GPIO_PIN_6, GPIO_PIN_SET);          if (HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_3)) {                measure ++;             }       measure = measure*2;       HAL_GPIO_WritePin(GPIOA, GPIO_PIN_6, GPIO_PIN_RESET);       }       HAL_GPIO_WritePin(GPIOA, GPIO_PIN_6, GPIO_PIN_SET);

   } else{

         __NOP();       }   }

show and measure declared as global

measure is valid in the      void

 HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)    scope

but become  0x1FFFFFE in main () when show = measure

Thanks

[Tesla DeLorean]

Posted on June 14, 2017 at 16:55

Probably because you're causing PA3 to bang up and down in an interrupt that triggers on PA3?

Consider using a flag to indicate if it filled the variable, or queuing the measurements, so you can see if the routine has entered multiple times.

[amelendez]

Posted on June 14, 2017 at 17:17

I have added a new global variable variable iterac

uint8_t iterac;

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)

{ uint8_t i; if(GPIO_Pin== GPIO_PIN_3) { newData = 1; HAL_GPIO_WritePin(GPIOA, GPIO_PIN_6, GPIO_PIN_RESET);

measure

= 0; for (i=0; i<24;i++) { HAL_GPIO_WritePin(GPIOA, GPIO_PIN_6, GPIO_PIN_SET); if (HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_3)) {measure ++; }

measure

=

measure

*2; HAL_GPIO_WritePin(GPIOA, GPIO_PIN_6, GPIO_PIN_RESET); } HAL_GPIO_WritePin(GPIOA, GPIO_PIN_6, GPIO_PIN_SET); } else{ __NOP(); } iterac = i;}

debugging (breakpoint at iterac = i) I see that the callback always return when iteract = 24 (that is i=24)

and measure is 0x0100033E

after 24 pulses at PA6, PA3 has been 0x0100033E. That is, there have been edges at PA3 but the interruption has only executed once.

[Tesla DeLorean]

Posted on June 14, 2017 at 18:02

>>

I see that the callback always return when iteract = 24 (that is i=24)

Well no doubt, I'm suggesting that the interrupt is reentering, not preemptively.

Make iteract a 32-bit free running counter, ie don't reset it to zero at each interrupt entry, or to the loop count.

In your main loop printf() iteract and show/measure to the SWV console.

[Tesla DeLorean]

Posted on June 14, 2017 at 18:08

Why the heck is everything being moderated today?

volatile uint32_t iterac = 0;

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)

{uint8_t i;

iterac++; // Entry count

if(GPIO_Pin== GPIO_PIN_3) {

newData = 1;HAL_GPIO_WritePin(GPIOA, GPIO_PIN_6, GPIO_PIN_RESET);

measure

= 0;for (i=0; i<24;i++){HAL_GPIO_WritePin(GPIOA, GPIO_PIN_6, GPIO_PIN_SET);if (HAL_GPIO_ReadPin(GPIOA, GPIO_PIN_3)){measure ++;}

measure

=

measure

*2;HAL_GPIO_WritePin(GPIOA, GPIO_PIN_6, GPIO_PIN_RESET);}HAL_GPIO_WritePin(GPIOA, GPIO_PIN_6, GPIO_PIN_SET);} else{__NOP();}}

...

   while (1)   {

      if (measure != 0xFFFFFFFF)

     {

        show = measure;

        measure = 0xFFFFFFFF;

        printf('%08X %08X\n', iterac, show);

      }

   }

[amelendez]

Posted on June 14, 2017 at 18:21

iterac continously increasing

show and measure 0x01FFFFFE

[Tesla DeLorean]

Posted on June 14, 2017 at 18:59

And that's not what you see when you break-point the exit of the IRQ? Don't single step the clocking

Using what tools? Or what processor/board?

[amelendez]

Posted on June 15, 2017 at 08:42

I'm configuring the board by means STM32CubeMX

The processor is the STM32L100RC

The board is designed by me

I'm going to review the hardware. Perhaps a noise glitch in the EXTI/DataIN (PA3) is triggering the interrupt