2018-12-12 07:40 AM
Hello,
I implemented a simple function generator as part of a project with a NUCLEO-L496ZG-P board.
A cosine signal is generated using TIM2 (internal clock, no prescaler, period set by ARR value) -> DMA (with 256 point cosine table in memory) -> DAC (triggered by TIM2 update), which works properly.
Now I'd like to add a TTL-style trigger signal phase locked with the cosine signal on an additional output.
I tried using another TIMer (I tried different ones, but let's just use TIM3 for this example now) in slave mode (ext. clock mode 1, Trigger Src. ITR1, PWM mode (tried different channels)) with an ARR value of 255 and CCRx of 128. This should give me the desired 50% duty cycle trigger signal I'd like to have.
Instead the pulse length is always exactly ONE TIM3 clock duration (derived from TIM2 update), as if CCRx was fixed to 1. If I change CCRx to one of the limits (0,ARR), the pulse vanishes as expected, but any value in between gives the same pulse length. Changes to ARR yield the expected behaviour and change the frequency of the pwm output.
This happens in the ext. clock mode 1, but not if the clock is the internal source. If I set TIM3 to internal clock, no trigger, no slave mode and the prescaler to the value of TIM2 ARR, with TIM3 ARR = 255, then I get the expected behaviour and can set the pulse length with CCRx.
Of course now there can be a small delay/offset between the start of the timers, so this workaround would need an additional OPM timer to synchronize the start on a hardware level. I'd like to circumvent this. Also I'm afraid that the slave mode needed for sync (e.g. reset mode) might also cause the same problems, but I did not have the time to test that yet.
I'd like to know if this is a bug or intended behaviour and wheter there is an option I did miss.
Thanks
Solved! Go to Solution.
2018-12-12 10:38 AM
2018-12-12 08:01 AM
Read out and post the TIM2 and TIM3 registers' content.
JW
2018-12-12 09:39 AM
2018-12-12 09:40 AM
2018-12-12 09:40 AM
2018-12-12 10:38 AM
Clear TIM3_CCMR1.OC1FE.
JW
2018-12-13 12:23 AM
This did indeed solve the problem.
Thank you very much for you fast help.