STM32F7 frequency capture on NUCLEO_F746ZG problems...

[Ed Sutter]

Posted on May 17, 2018 at 21:31

Hi, I am working with STM32Cube_FW_F7_V1.11.0 on a Nucleo_F746ZG.

Seems like what I wanna do should be simple, but I'm not getting it...

I need to measure the frequency of something, so I started with Projects/STM32F746ZG-Nucleo/Examples/TIM/TIM_InputCapture.  This uses TIM3 on GPIOB-Pin5 as the input capture pin.

To test, I just wanted to see the interrupt handler get hit if I pulsed that pin, but I noticed that as soon

as I momentarily ground that pin the board hangs.  Looking at the HAL_TIM_IC_MspInit() function that

comes with the example...

void HAL_TIM_IC_MspInit(TIM_HandleTypeDef *htim)

{       GPIO_InitTypeDef GPIO_InitStruct;

TIMx_CLK_ENABLE();

TIMx_CHANNEL_GPIO_PORT();

GPIO_InitStruct.Pin = TIMx_GPIO_PIN_CHANNEL2;

GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; GPIO_InitStruct.Pull = GPIO_PULLUP; GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH; GPIO_InitStruct.Alternate = TIMx_GPIO_AF_TIMx; HAL_GPIO_Init(TIMx_GPIO_PORT, &GPIO_InitStruct);

HAL_NVIC_SetPriority(TIMx_IRQn, 0, 1);

       HAL_NVIC_EnableIRQ(TIMx_IRQn);}

This is straight out of Cube (with comments removed).

It seems odd that an input pin would be configured as push-pull (GPIO_MODE_AF_PP)...

Does anyone know if this is tested code?  If it is, any suggestions as to why

it hangs for me?

#tim3-input-capture #stm32f7

[T J]

Posted on May 18, 2018 at 01:34

Are you sure you have set the cube configuration page ?

if you would like to send the cube file, I can take a look for you.

[Tesla DeLorean]

Posted on May 18, 2018 at 03:43

In AF mode the peripheral has significant control of the pin driver, it can definitely control direction (input vs output). The sense of pins on say SPI can change whether you tell the peripheral you're a master or slave.

When used as an output you can control the use of PP or OD modes, and as an IO the pull up/down options.

[Tesla DeLorean]

Posted on May 18, 2018 at 03:47

I would tend to use TIM2 or TIM5, (32-bit TIMs) as they can clock very quickly on an F7 in maximal mode. With 16-bit TIM you have to pay attention to the wrap time, as this will put a lower limit on the frequencies that can be measured.

Periodicity can be computed by looking at the delta count in TIMx->CCRx time stamp of two most recent rising edges.

The use of PWM Input can reset the TIM such that period and duty can be latched in CCR1/CCR2

[Ed Sutter]

Posted on May 18, 2018 at 14:12

I guess I'm not sure what you mean by the 'cube configuration page'.  I don't use any GUI to build/debug, just 'make' and the ST_LINK USB tool to program the board.  I just create a directory that is essentially a peer to the other builds (EWARM, MDK-ARM, SW4STM32, etc...) and build a makefile from the .project/.cproject files of SW4STM32.  I've built a few other examples that way and they've worked fine.  

I don't use the STM32CubeMX graphical configuration tool, I was assuming the 'Examples' directory for the various eval boards in CUBE were complete and that STM32CubeMX was only needed if I was building something from scratch.

Am I missing something?

[Ed Sutter]

Posted on May 18, 2018 at 14:18

Totally agree... I just wanted to start with what I thought would be a known-to-work example from CUBE.

[Ed Sutter]

Posted on May 18, 2018 at 14:25

Ok, so that tells me that its probably not really in push-pull mode (which as far as I know would make the pin an output); but that the AF configuration is really the 'boss' of the pin.  Unless I missed it, there doesn't seem to be a lot of documentation in the reference manual on how the various AF modes configure the pin.  I've been depending on the reference manual and datasheet, is there something else?

Anyway, the bottom line here is I'm just using the example code that came with CUBE.  I was hoping to use that as a starting point.  Is that a bad assumption?