Skip to main content
arnaljl
Associate III
May 18, 2017
Question

Cube32MX - input capture overflow detection.

  • May 18, 2017
  • 16 replies
  • 4243 views
Posted on May 18, 2017 at 22:46

Hi.

I'm trying to use TIM1's channel 1 as a spindle RPM input capture. ( device is STM32F103C8 )

Knowing that the spindle has a single pulse per revolution and is rated from 0 to 30K rpm, the frequency domain is 0 to 500Hz. Easy feat for a timer running at 48MHz.

So I configured TIM1's prescaler to 480, its period to 0xFFFF, direct input, no prescaling nor filtering (sharp input signal)...

So far so good, frequencies from 5Hz to 1KHz  are registering nicely...

But here's my issue : I was planning to count the number of UPDATE interrupts to detemine when the signal's period dropped too much ( i.e. the spindle was idling ).

BUT : it seems that I'm missing some UP events. The update interrupt isn't always firing.

Here's my code. The first method is CubeMX's output.

/* TIM1 init function */

static void MX_TIM1_Init(void)

{

  TIM_ClockConfigTypeDef sClockSourceConfig;

  TIM_MasterConfigTypeDef sMasterConfig;

  TIM_IC_InitTypeDef sConfigIC;

  htim1.Instance = TIM1;

  htim1.Init.Prescaler = 512;

  htim1.Init.CounterMode = TIM_COUNTERMODE_UP;

  htim1.Init.Period = 0xFFFF;

  htim1.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;

  htim1.Init.RepetitionCounter = 0;    

  if (HAL_TIM_Base_Init(&htim1) != HAL_OK)

  {

    _Error_Handler(__FILE__, __LINE__);

  }

  sClockSourceConfig.ClockSource = TIM_CLOCKSOURCE_INTERNAL;

  if (HAL_TIM_ConfigClockSource(&htim1, &sClockSourceConfig) != HAL_OK)

  {

    _Error_Handler(__FILE__, __LINE__);

  }

  if (HAL_TIM_IC_Init(&htim1) != HAL_OK)

  {

    _Error_Handler(__FILE__, __LINE__);

  }

  sMasterConfig.MasterOutputTrigger = TIM_TRGO_RESET;

  sMasterConfig.MasterSlaveMode = TIM_MASTERSLAVEMODE_DISABLE;

  if (HAL_TIMEx_MasterConfigSynchronization(&htim1, &sMasterConfig) != HAL_OK)

  {

    _Error_Handler(__FILE__, __LINE__);

  }

  sConfigIC.ICPolarity = TIM_INPUTCHANNELPOLARITY_FALLING;

  sConfigIC.ICSelection = TIM_ICSELECTION_DIRECTTI;

  sConfigIC.ICPrescaler = TIM_ICPSC_DIV1;

  sConfigIC.ICFilter = 0;

  if (HAL_TIM_IC_ConfigChannel(&htim1, &sConfigIC, TIM_CHANNEL_1) != HAL_OK)

  {

    _Error_Handler(__FILE__, __LINE__);

  }

    

}

// Some global variables

volatile bool _toolRawRevValid;

volatile uint32_t _lastTim1CC,_toolRawRev, _tim1Ovf ;

void InitializeInputStage(void)

{

    // prepare variables 

  _toolRawRev = 0;

    _toolRawRevValid = false;

    _tim1Ovf = 0;

    _lastTim1CC = 0;

    

    // Start TIM1 and its interrupts (as configured in MX_TIM1_Init() ).

    HAL_TIM_Base_Start_IT(&htim1); // start counting, enable UPDATE interrupt

    HAL_TIM_IC_Start_IT(&htim1, TIM_CHANNEL_1); // enable IC interrupt (already counting now).

}

// Auto-reload (update) event interrupt handler

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)

{

    if(htim == &htim1)

    {

        _tim1Ovf++; // count roll-overs.

        if(_tim1Ovf >= 2)

            _toolRawRevValid = false;

    }

}

// Timers Capture handler

void HAL_TIM_IC_CaptureCallback(TIM_HandleTypeDef *htim)

{

    register uint32_t currCap, ovf, tc;

    

    if(htim == &htim1){

        currCap = HAL_TIM_ReadCapturedValue(&htim1, TIM_CHANNEL_1);

        tc = TIM1->CNT;

        ovf    = _tim1Ovf; // number of TIM1-CNT rollovers

        _tim1Ovf = 0;

        

        if(currCap <= _lastTim1CC) {

            if(!ovf){ // no roll-over occured ?

                while(1)

                    __NOP; // the previously captured value is higher than the current one, but no timer overflow registered ?

            }

            _toolRawRev = ((TIM1->ARR * ovf) + currCap )-_lastTim1CC;

        }else{

        _toolRawRev = (TIM1->ARR * ovf) + (currCap - _lastTim1CC);

        }

        _toolRawRevValid = true;

        

        _lastTim1CC = currCap;

        }

    

}

So here's the strange fact : my program keeps hitting the __NOP statement in the HAL_TIM_IC_CaptureCallback(...) method.

Is Timer1 gated by its input capture somehow ?

PS: sorry for the repetitive edits, I'm discovering the community's new interface. =/

#stm32f1 #isr #missing #input-capture #interrupt
This topic has been closed for replies.

16 replies

arnaljl
arnaljlAuthor
Associate III
May 18, 2017
Posted on May 18, 2017 at 23:09

What troubles me most is this : if the second capture sample is lower that the fist, there SHOULD be an overflow registered between the two edges we detected, right ?

waclawek.jan
Super User
May 18, 2017
Posted on May 18, 2017 at 23:21

Does the update interrupt fire at all?

TIM1 in many STM32 has separate interrupts for the update and for CC. If your STM32 model has it so, does it have both enabled in NVIC and directed properly towards the Cube mess? (I don't Cube so don't know how to do that).

JW

arnaljl
arnaljlAuthor
Associate III
May 18, 2017
Posted on May 18, 2017 at 23:59

Well, that's both an easy and a tricky question.

Yes, the update interrupts occurs ( I do reach it if I set a breakpoint on the line

'_tim1Ovf++; // count roll-overs.'

when the infinite NOP is commented out.

Plus, it tried to diss the HAL methods to start timer1 directly : nothing changed.

As a matter of fact, I ensured to set the UP¨interrupt to a lower rank than the CC to be sure it would be fired first.

I added the infinite NOP

 if(!ovf){ // no roll-over occured ?

     while(1)

     __NOP;

 }

sequence for debug purposes, since I wasn't conviced the MCU misfired its UP interrupt. But it looks like it does.

But as soon as the signal frequency drops under 5Hz ( and TIM1->CNT reach a big value ), it all goes haywire and the UP isr doesn't fire anymore ( CC doesn't fire as well ).

waclawek.jan
Super User
May 18, 2017
Posted on May 19, 2017 at 01:09

Is _tim1Ovf declared with volatile qualifier?

I ensured to set the UP¨interrupt to a lower rank than the CC to be sure it would be fired first.

You mean, the update interrupt having higher priority, thus being able to nest/interrupt/preempt the CC interrupt service routine? With the above code, that should avoid reading unupdated (unincremented) _tim1Ovf  after having read an overflown TIM1->CNT (provided that _tim1Ovf is volatile, TIM1->CNT is defined as volatile in the CMSIS-mandated device header). However, you might read TIM1->CNT not yet overflown, the overflow happening just after having read TIM1->CNT, and _tim1Ovf is then already incremented.

Draw diagrams with all possible sequence of events. This problem does not have a trivial solution.

JW

arnaljl
arnaljlAuthor
Associate III
May 19, 2017
Posted on May 19, 2017 at 02:09

 ,

 ,

Yes, the UPDATE interrupt preempts the CC interrupt in my NVIC initialization , ( UPDT rank is 2 and CC is 3 ).

/** NVIC Configuration */

 ,

static void

MX_NVIC_Init(

void

)

 ,

{

 ,

 ,

/* USB_HP_CAN1_TX_IRQn interrupt configuration */

 ,

 , HAL_NVIC_SetPriority(USB_HP_CAN1_TX_IRQn, 1, 0),

 ,

 , HAL_NVIC_EnableIRQ(USB_HP_CAN1_TX_IRQn),

 ,

 ,

/* USB_LP_CAN1_RX0_IRQn interrupt configuration */

 ,

 , HAL_NVIC_SetPriority(USB_LP_CAN1_RX0_IRQn, 5, 0),

 ,

 , HAL_NVIC_EnableIRQ(USB_LP_CAN1_RX0_IRQn),

 ,

 ,

/* TIM interrupts ranking */

 ,

 ,

 , HAL_NVIC_SetPriority(TIM1_UP_IRQn, 2,0),

 ,

 , HAL_NVIC_SetPriority(TIM1_CC_IRQn, 3,0),

 ,

}

I simplified my code a bit to see if I could shift the problem and make it more obvious, but I still stumble upon strange results, relating to the previous capture being 'bigger' than the new one.

/* let's make a 32-bits counter out of TIM1->,CNT by holding its overflows into the MSW of a DWORD (all unsigned ) */

♯ pragma

anon_unions

 ,

typedef union

{

 ,

 , ,  ,__packed

struct

{

 ,

 , ,  , , ,  ,

uint16_t

word0,

 ,

 , ,  , , ,  ,

uint16_t

word1,

 ,

 , ,  ,}, , ,  , , ,  ,

 ,

 , ,  ,uint32_t dword, , ,  ,

 ,

}U32Composed_t,

volatile U32Composed_t

_currTim1CC, _lastTim1CC,

 ,

volatile uint16_t

_tim1Ovf,

 ,

volatile uint32_t

_toolRawRev,

void

HAL_TIM_IC_CaptureCallback(TIM_HandleTypeDef *htim)

 ,

{ , ,  ,

 ,

 , ,  ,if(htim == &,htim1){

 ,

 , ,  , , ,  ,

// we might get an spurious overflow here, but the bugs said otherwise.

 ,

 , ,  , , ,  ,_currTim1CC.word1 = _tim1Ovf,

 ,

 , ,  , , ,  ,

// get the captured count and concatenate as lower word. ,

 ,  , , , ,  , , , , , , , , ,

 , , , , , , , _currTim1CC.word0 = TIM1->,CCR1,

 ,

 , ,  , , ,  ,

 ,

 , ,  , , ,  ,if(__HAL_TIM_GET_FLAG(&,htim1,TIM_FLAG_UPDATE))

 ,

 , ,  , , ,  , , ,  ,_currTim1CC.word1++,

 ,

 ,

 , ,  , , ,  ,_toolRawRev = _currTim1CC.dword - _lastTim1CC.dword,

 ,

 , ,  , , ,  ,_toolRawRevValid = true,

 ,

 ,

 , ,  , , ,  ,_lastTim1CC.dword = _currTim1CC.dword,

 ,

 , ,  ,} , ,  ,

 ,

}

 ,

 ,

void

HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)

 ,

{

 ,

 , ,  ,if(htim == &,htim1)

 ,

 , , , ,

 , _tim1Ovf++, // count roll-overs.

 , ,  , , , ,

 , , ,

 ,

}

 ,

Despite this, , _currTim1CC.dword , manages to be LOWER than _lastTim1CC.dword on frequencies lower than 5Hz !

 ,

 ,

In other words, the only volatile value which MSW could be incremented in a nested UPDATE interrupt , still manages to be lower than its previously saved value.

 ,

I'm at a loss here.

 ,

 ,

It's as if TIM1 was gated by its own input capture channel somehow : as soon as I cut the input signal, I get no more _

tim1Ovf

increments ! No more UPDATE interrupts !

 ,

waclawek.jan
Super User
May 19, 2017
Posted on May 19, 2017 at 11:46

Does the update interrupt fire at all?

TIM1 in many STM32 has separate interrupts for the update and for CC. If your STM32 model has it so, does it have both enabled in NVIC and directed properly towards the Cube mess? (I don't Cube so don't know how to do that).

[

Yes, I know I re-asked the same question. No, you don't prove update interrupts being fired by update, just by placing a breakpoint in the callback - the callback will get called back from a different interrupt.

If I am right in this, this is a deserved punishment for using a 'library'.

]

JW

Tesla DeLorean
Guru
May 18, 2017
Posted on May 19, 2017 at 01:17

Prescaler is an N-1 value, assuming you don't want a division by 481 or 513?

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
arnaljl
arnaljlAuthor
Associate III
May 19, 2017
Posted on May 19, 2017 at 02:11

the value of the prescaler is trivial here. Non sequitur the weird period captures.

Plus, the result RPM is calculated as a float in the main loop, so multiplication/division aren't an issue since I already sacrificed computing speed over floating point ( STM32F1xx series have no FPUs )
Tesla DeLorean
Guru
May 19, 2017
Posted on May 19, 2017 at 04:09

I'd use the DWT_CYCCNT to be the 32-bit timebase of record with which to quantify the overflow of the 16-bit counters. At 72 MHz, that's about a minute as I recall. So get a rough time delta for the IRQ entry, and use that to qualify the hardware edge measurement you get from the TIM

Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
arnaljl
arnaljlAuthor
Associate III
May 20, 2017
Posted on May 20, 2017 at 15:10

Gosh, I'm so upset and ashamed of myself.

Turns out the culprit was the function generator I used on my test bench.

This horrible piece of chinesium won't output anything at 4hz, and creates high-piched harmonics at very low frequencies, around 1Hz and 2Hz.

But its signal is clean and spotless above 5Hz !

The code was functional all along -_-.

Anayway, thanks you guys for your interest and support !

Guess I'll have to buy a new signal generator =/

henry.dick
Associate II
May 12, 2018
Posted on May 12, 2018 at 19:47

You can simply config one of pwm channels to generate something like that. That way you know for sure what signal you should expect.

jean-christophe Toussaint
Associate III
May 12, 2018
Posted on May 12, 2018 at 17:35

Dear Jla

I have produced a small tutorial based on the application note AN2592 'Achieving 32 bit timer resolution with software expansion for STM32Cube'. I used a STM32L053 MCU which does not own any 32 bit timer or DWT cycle counter.

May I expect that it will be useful for you. Do not hesitate to give me back your feel back.

Sincerely yours

JC Toussaint

https://community.st.com/0D50X00009bMMA8SAO

 
henry.dick
Associate II
May 12, 2018
Posted on May 12, 2018 at 19:43

Easy.

1. Enable the time base overflow interrupt and

2. In its isr, increment a counter. If you pick that counter to be a 32 bit type. To gather with a 16 bit timer counter you have a 48bit timer.

You can then detect 0 frequency in the isr.