STM32F769 Discovery board capturing input on timer 3

[MPlan.7]

I am trying to capture input from an external source. Using CubeMX as a guide, I configured timer 3 like this:

/* TIM3 init function */
void MX_TIM3_Init(void)
{
  // PC8 ------> TIM3_CH3 
  TIM_IC_InitTypeDef sConfigIC = {0};
  GPIO_InitTypeDef GPIO_InitStruct = {0};
 
  htim3.Instance = TIM3;
  htim3.Init.Prescaler = 0;
  htim3.Init.CounterMode = TIM_COUNTERMODE_UP;
  htim3.Init.Period = 0xFFFFFFFF;
  htim3.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;
  htim3.Init.AutoReloadPreload = TIM_AUTORELOAD_PRELOAD_DISABLE;
  HAL_TIM_IC_Init(&htim3);
 
  sConfigIC.ICPolarity = TIM_INPUTCHANNELPOLARITY_RISING;
  sConfigIC.ICSelection = TIM_ICSELECTION_DIRECTTI;
  sConfigIC.ICPrescaler = TIM_ICPSC_DIV1;
  sConfigIC.ICFilter = 0;
  HAL_TIM_IC_ConfigChannel(&htim3, &sConfigIC, TIM_CHANNEL_3);
 
  GPIO_InitStruct.Pin = GPIO_PIN_8;
  GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
  GPIO_InitStruct.Pull = GPIO_NOPULL;
  GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
  GPIO_InitStruct.Alternate = GPIO_AF2_TIM3;
  HAL_GPIO_Init(GPIOC, &GPIO_InitStruct);
  
  __HAL_RCC_TIM3_CLK_ENABLE();
  __HAL_RCC_GPIOC_CLK_ENABLE();
  HAL_TIM_IC_Start(&htim3, TIM_CHANNEL_3);
}

But when I connect a signal generator to PC8, all I get is ~43500 counts per second, even when the generator is off.

Can anyone suggest what I have configured incorrectly? Or, for that matter, if PC8 really is the correct pin for timer 3, channel 3.

[waclawek.jan]

> all I get is ~43500 counts per second

Where, how do you get that?

TIM3_CCR3 does not change?

> anyone suggest what I have configured incorrectly?

I don't speak the Cube gobbledygook but you can always read out the timers (and relevant GPIOs) registers content and check.

> if PC8 really is the correct pin for timer 3, channel 3.

Check yourself in the given STM32's datasheet.

[MPlan.7]

I get that value by reading the CNT register for timer 3, using the function __HAL_TIM_GetCounter(). I know it works because I can configure timer 3 as a regular free-running clock and read the expected values. I don't understand the reference to TIM3_CCR3; I'm not capturing the value at an event, but rather simply checking it once per second (as part of the HAL_TIM_PeriodElapsedCallback() function for timer 2, which is running the STemWin GUI interrupts).

The problem is that the pin is not responding to input signals. I assume this has something to do with how it is configured. While I agree I am less than impressed with the CubeMX output, the goal of my current task is to evaluate this chip for a future project. Getting it working is less important than understanding how helpful the various tools and middleware are. As you note, so far this part of the evaluation is going quite poorly.

Of course I've checked PC8 in the manual. Also on the card that came with the board and in CubeMX, which is how I discovered that apparently its related to GPIO_8. But documentation can be wrong; or more likely, the Discovery board has already committed that pin to some other use and so all I am doing is creating a conflict. I would check this myself but STMicro does not see fit to supply the .ioc file for the Discovery board. So I thought I would ask for advice, as the technical support for this product is also part of my evaluation.

[S.Ma]

Once the assesment is completed, thanks to share it on this forum.

[MPlan.7]

Some more detail:

I switched to Tim1 channel 4 because it's available on PA11. CubeMX generated very similar code to the tim3 case. Note that CubeMX never calls the _Start function. I now get the same result, except the value is ~21500. This value changes if I change my GUI clock (i.e. if I slow the GUI down by half this number gets cut in half).

So clearly I have not convinced the timers to count from the external pins. I just can't think of anything else to try. I configure a timer, I configure a GPIO pin, then I enable and start them. What else do I need to do?

[S.Ma]

I have not convinced the timers to count from the external pins.

Heu CubeMX doesn't explain how to use the timer in typical application configuration

If you want to use an external signal as timer clock to count how many edges, then it should be channel 1 or 2 or ETR pin.

If you want to measure a period or duty cycle, you need a timer count up in freerun mode with overflow which period is longer than the one to measure, and input captures with interrupt or DMA to measure for example the timer distance betweek 2 falling edge (period).

If the frequency is below 1 kHz you could just use EXTI on the pin and capture the SYSTICK timer or RTC...

[MPlan.7]

I was just coming back to note that I tried using TIM12 with PH6 and setting it into External Clock mode instead of Direct Input Capture mode (as suggested by this post https://community.st.com/s/question/0D50X00009XkaNXSAZ/using-a-timer-to-count-pulses-on-stm32f7). And got the same result - the timer counts with the main system clock. Although that guy seems to have gotten his working, though I can't figure out how.

I haven't tried to use the ETR pin because I am working with the Discovery board and none of those pins are exposed. I don't know what you mean by channel 1 or 2; could you clarify?

I do want to count edges - in my case, each pulse is a discrete event (a photon striking a detector). Thanks for the confirmation on how difficult this task is.

[MPlan.7]

Briefly,

• CubeMX and TouchGFX didn't work out of the box for me, one because there was no .ioc file for their own board and the other because the example project wouldn't load.
• The chip seems overly elaborate; every timer, for instance, is almost unique in its configuration and abilities. There are heavy optimizations for things I don't care about (like Hall sensors).
• Documentation was spotty. Lots of examples is a positive but many of them poorly written, and they can't seem to agree on registers, LL, or HAL layer as an approach.
• The HAL did not impress me. A common function for handling all timer interrupts of a particular class is the default, even while the code clearly supports individual callback functions. But what was missing was instructions on how to enable individual callback functions. I mean, I could have just edited the code as necessary, but that hardly seems like the correct approach.
• I didn't even make it to the stage of evaluating the RTOS.

Meanwhile, I achieved everything I tried to do on a different product in two weeks, including setting up a mutli-threaded touch screen application that I understood and felt comfortable with. If you're already invested in ST technology, you should completely ignore my comments. But then, if you're already into ST, you probably didn't buy a Discovery board.