tim3 interrupt not getting cleared

[Brad Stewart]

Posted on July 06, 2018 at 00:09

I'm new to ST but have extensive experience with Eclipse and other ARM M cores..

I created a simple 'blinky' program using STM32CubxMX and ST32M System Workbench on a STM32F769-DISC0 Discovery Board.

The LED toggles once during an interrupt.  Then the interrupt no longer gets invoked.  It's like the irq flag is not reset.

But as I trace through stm37f7xx_hal_tim.c, the following macro to clear the RS bit is executed on the first interrupt after a reset.

 __HAL_TIM_CLEAR_IT(htim, TIM_IT_UPDATE);

I am following the example in Chapter 7 of the UM1718.pdf '

STM32CubeMX for STM32 configuration

and initialization C code generation'.  I'm am not using any middle-ware and is bare-metal.  Only the HAL layers.

It's a simple program that uses tim3 to toggle PJ13 (LD_USER1).  It toggles the first time but then the interrupt is never triggered.

Attached is my Cube project file and main.c

Please help as I have no idea why this isn't working.

#timer-interrupts #use-stm32f769-discovery-board

[waclawek.jan]

Posted on July 06, 2018 at 09:26

It's like the irq flag is not reset.

If the IRQ flag would not be reset, the interrupt would fire repatedly indefinitely.

  htim3.Init.Period = 0;

This means, the timer is not running (thus can't interrupt when rolls over, a.k.a. at Update Event).

bare-metal.  Only the HAL layers.

Cube/HAL is definitively not what's considered bare metal in microcontrollers.

JW

[henry.dick]

Posted on July 06, 2018 at 12:46

'

It toggles the first time but then the interrupt is never triggered.'

without seeing your code, it is tough to tell - your period could be too long, for example.

the best bet is to see the values in the registers related to the timer so you know for sure if they are correctly configured - HAL isn't that reliable.

'

Cube/HAL is definitively not what's considered bare metal in microcontrollers.'

debatable. often times bare metal refers to programming without an OS.

[Brad Stewart]

Posted on July 06, 2018 at 19:08

Setting the counter period to a value other than 0 fixed the issue.  Thank you.

However, look at Figure 176 in the UM1718 and it shows the counter value as zero.

Regarding the definition of ''bare-metal'', it is generally defined as firmware that runs without an operating system.  Since I am not using FreeRTOS, it's bare-metal.