stm32f40x discovery TIM9 and TIM12 PWM input capture

[philsax]

Posted on April 23, 2014 at 15:33

hi all,   I'm new in the forum and I am experiencing a problem of ISR , which doesn't  happen for TIM12 while, with same ch1 configuration register and same pwm signal input,  set the ISR calling for TIM9, as expected.  I am quite surprised of this behaviour and I have checked the TIM9 and TIM12 register configuration  but I cant found any difference .  I am about to check if there is any errata which may affect the TIM12 functionality: not yet done at the moment.  do you have any suggestion?  I am new to stm32 device and maybe someone can give me some tips on what to check and debug(keil V5)  .  

[Tesla DeLorean]

Posted on May 10, 2014 at 23:14

Do you ever experiment peripheral reset and reconfiguration issue?

I've done a lot of experimentation. I'm pretty sure I've build a multi-channel frequency/pulse measurement. It is important to keep the context measurements for each channel separate. I've also definitely reconfigured things. Remember of the F4 that the pin configurations are now separate from the peripheral, and thus a reset of the peripheral might change a pin setting/direction, it won't alter which pin is in play.

[philsax]

Posted on May 13, 2014 at 12:03Hi, Because I found measurement issues when I switch the input peripheral, whereas I can get stable and correct ( uninfluenced by  unused TIM input ) measurement when I do only startup configuration,  after device restart,  I thought  to try a reconfiguration after a peripheral reset procedure,  but,   when I add a pheripheral reset ,  I fall into problem:  so I ask for suggestion on  peripheral reset procedure.  I'm pretty sure some of you had already done such kind of things.   The one I have applied  is a simple register  setup '1'  and immediatly reset to '0'  as follow:// reset Tim9 peripheral to allow reconfigurationRCC -> APB2RSTR  |= (1UL << 16);// remove resetRCC -> APB2RSTR  &= ~(1UL << 16);// reconfigure the next active channel......My doubt was on the reset time '1' and '0' applied,  nearly few nanoseconds far  ... : is there a timing restrictions on reset procedure?  I didn't  found specific info on the documentation.  would be the upper procedure correct to obtain a peripheral reset?... When I do reconfiguration I have to leave RCC clock signal connected? ( I think so...) During reconfiguration  I do full GPIO pin reconfiguration,  The following is one of the two switching branch  applied  for  the  input pin,  // disable timer9 before switch the input PWMTIM9 -> CR1 &= ~(TIM_CR1_CEN );// ------- configure   timer9  input #2  : disconnect PE6  ------------ GPIOE -> MODER &= ~((uint32_t)(3UL << 12));                                              GPIOE -> MODER |= ((uint32_t)(1UL << 12));             GPIOE -> OTYPER |= ((uint32_t)(1UL << 6)); GPIOE -> OSPEEDR |= ((uint32_t)(3UL << 12));                       GPIOE -> PUPDR &= ~((uint32_t)(3UL << 12));                       GPIOE -> AFR[0] &= ~((uint32_t)(15UL << 24));                   // set the output to logic '1', to unaffect the input signal connectedGPIOE -> ODR   |= ((uint32_t)(1UL << 6));                     //  connect PE5, timer input #1 to TIM9: re-enable alternate functionGPIOE -> MODER &= ~((uint32_t)(3UL << 10));                       GPIOE -> MODER |= ((uint32_t)(2UL << 10));                       GPIOE -> OTYPER &= ~((uint32_t)(1UL << 5));                      GPIOE -> OSPEEDR |= ((uint32_t)(3UL << 10));                      GPIOE -> PUPDR &= ~((uint32_t)(3UL << 10));                       GPIOE -> PUPDR |= ((uint32_t)(2UL << 10));                       GPIOE -> AFR[0] &= ~((uint32_t)(15UL << 20));                   GPIOE -> AFR[0] |= ((uint32_t)(3UL << 20));      // follow  TIM9 channel configuration...//--------------------------------------------------------------------------------      // leave the same CCxP and CCxNP  configuration for both channel  TIM9 -> CCER =  0x31;// disable temporarily for next register configTIM9 -> CCER &=  ~( TIM_CCER_CC1E | TIM_CCER_CC2E );   // !!SEQUENCE NOTE:  CC1S and CC2S are writable only when // CC1E and CC2E of CCER are zeroTIM9 -> CCMR1 = 0x3231;     // 8 sample filter for IC1 and IC2// enable  CC1E and CC2E  after CCxS configuration // leave the same CCxP and CCxNP  configuration for both channel  TIM9 -> CCER |=  ( TIM_CCER_CC1E | TIM_CCER_CC2E );   TIM9 -> SMCR = 0xD4; // trigger selection channel #1 - PE5// TIE:0: disable; CC2IE:0 disable; CC1IE:1: enable; UIE:0: disable TIM9 -> DIER = 0x02; //  interrupt enable capture-compare 1 only// enable timer9 to measure  the input PWM selectedTIM9 -> CR1 |= TIM_CR1_CEN ;//-------------------------------------------------------------------------------------------------------------concerning the TIM channel configuration,  I can see the peripheral register value during my debug session  and I can see  Is correct  as I expect ,   so I don't think to investigate on that topic  to solve  the problem. I don't exclude  some subtle  configuration issue  or some other device set-up  that could affect my test environment,  and maybe  I didn' t  take into account.  Please don't esitate to make suggestion if you think that useful .I just  want to ask the community to get a feedback on the topic are not fully covered by documentation   to exclude some  known  issue I am not aware of ,  and to make further  steps  to succeed in realize a multi channel measurement PWM . Thanks 

[philsax]

Posted on May 19, 2014 at 09:24Hi all,  after some code refactor and keeping the measure context separated , I succeed in measuring 2 channel  PWM  input with TIM9 peripheral. I don't exclude also some bug in the reconfiguration code.I have applyed as long as 3 millisec ON and also OFF status .  I don't know if this reset cycle is strictly necessary but,  For my real-time application needs,  I can afford to wait so long between the two measure,  and I could leave the reset timing this way.  thank you for the suggestion!