cancel
Showing results for 
Search instead for 
Did you mean: 

Problems with TIM input capture

bjornpaulstrom
Associate III
Posted on October 11, 2016 at 19:08

Hello, I am having some difficulties with input capture on the nucleo64-r401re.

I manage to generate a PWM signal to a ultrasonic sensor, that replies correctly (checked with oscilloscope), however i do not manage to capture the returning data correctly it seems. The callback fires but the data it reads is always the same.

Here is my code:

http://paste.ofcode.org/wsXi8arKfbCxHGy3fBQBf9

Any ideas to what I am missing?
5 REPLIES 5
Walid FTITI_O
Senior II
Posted on October 11, 2016 at 20:28

Hi paulstrom.bjorn, 

I recommend that you cehck both example in the STM32CubeF4 wich are - * ''TIM_InputCapture'' at this path STM32Cube_FW_F4_V1.13.0\Projects\STM32F401RE-Nucleo\Examples\TIM\TIM_PWMInput

 * ''TIM_PWMInput'' example at this path STM32Cube_FW_F4_V1.13.0\Projects\STM32F401RE-Nucleo\Examples\TIM\TIM_PWMInput

Try to compare with you own code and figure out what is missed there (check timer instance parameter, system and timer clocks..).

-Hannibal-

bjornpaulstrom
Associate III
Posted on October 18, 2016 at 14:51

The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6jm&d=%2Fa%2F0X0000000buJ%2Fq9cqrd0WwMpx0ABXGzqh8ErX_r4vFzVDIzg6k39x_P4&asPdf=false
Posted on October 18, 2016 at 18:14

This looks to be using PWM Input, not Input Capture, as such value will keep resetting.

TIM2 should also be 32-bit, which would give you support for longer periods when clocking the counter at 84 MHz

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
bjornpaulstrom
Associate III
Posted on October 18, 2016 at 18:32

Hello clive1, and thank you for your answer 🙂

Yes you are correct, the period should be for 32bit instead of 16bit, forgot to change it from the STM examples which used TIM4 which is 16bit.

I think the code uses both input capture and pwm input, both on different channels, input capture on channel 2, and pwm input on channel 1:

void HAL_TIM_IC_CaptureCallback(TIM_HandleTypeDef *htim)

{

  if (htim->Channel == HAL_TIM_ACTIVE_CHANNEL_2)

  {

    /* Get the Input Capture value */

    uwIC2Value = HAL_TIM_ReadCapturedValue(htim, TIM_CHANNEL_2);

    

    if (uwIC2Value != 0)

    {

      /* Duty cycle computation */

      uwDutyCycle = ((HAL_TIM_ReadCapturedValue(htim, TIM_CHANNEL_1)) * 100) / uwIC2Value;

      

      /* uwFrequency computation

      TIM4 c

ounter clock = (RCC_Clocks.HCLK_Frequency) */

      uwFrequency = (HAL_RCC_GetHCLKFreq()) / uwIC2Value;

    }

    else

    {

      uwDutyCycle = 0;

      uwFrequency = 0;

    }

  }

}

That atleast is how I understood the example but my experience with IC and PWM is limited. Or have I misunderstood you and you mean the example only sets up a PWM input? How would i go about changing this to use input capture then?
Posted on October 18, 2016 at 18:59

Can't really help you with HAL, not my deal.

The Channels latch the counter, in PWM Input the counter gets reset, so you have a pair of channels one determining the total period (ie rising to rising) and the other the duty (rising to falling).

To understand what might be happening, and why it might be wrong, I'd need to understand the nature/frequency of the input signal, and the measurements you are observing for them.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..