STM32F334 HRTIM WITH BAD BEHAVIOR

[Asantos]

Posted on November 26, 2015 at 17:56

Hi,

I'm experiencing a very bad behavior of HRTIM.if output set register is set on Period and output reset register is reset on CMP1.if CMP1 = 0x20, the PWM output is a narrow pulse as expected. but if the CMP1 < 0x20 the output go to active state. The duty cycle goes to near zero to 100%. This is very bad!the section 10.3.6 of the RM0364 states that:if the set and reset events are generated within same HRTIM clock period, the reset event has the highest priority and the set event is ignored. But what is happening is the opposite of it.Someone else noticed this issue before or I'm missing something?

[mikael239955_stm1_st]

Posted on November 26, 2015 at 21:19

Hi!

Well , the HRTIM is complex peripheral to say the least.There are min and max limits of PER and CMP values depending on what you have set PSC to.For example if; HRTIM1_TIMD->TIMxCR |= HRTIM_TIMCR_CK_PSC;  //divide by 128Then PER and CMP min is 3 and max is 65533. The lesser value of PSC the range becomes narrower.Beyond these max and min values the timer/comparator seams to slam into high and low states as younoticed but also somewhat erratically as i can see from my own tests.I have issues even within min max limits using max clk of 4.06Ghz 8bit format gives strange bendsin PW wave when approaching min max values so i have to use more then 8 bits to actually get 8bits.Also the reset of timer is not behaving in the same way as regular advanced/general/basic timers.HRTIM causes a nasty double sided reset (PER swep test) sort of.The page your referring to HRTIM starts at 21, and not 10.3.6. The section page your referring to is this: This section describes how the output waveform is generated when severalset and/or reset requests are occurring within 3 consecutive tHRTIM periods.The case1 suggest the arbitrating among set/reset sources.   

[Asantos]

Posted on November 27, 2015 at 00:35

Mikael,

 on page 643 of the RM0364 it is written:  ''

If the set and reset events are generated within the same

t

HRTIM

period, the reset event has

the highest priority and the set event is ignored.''

     So, in my understand if the CMP1 <= 32, The Set and Reset events occurs in the same tHRTIM period, the first one after timer reloads, so the set event should be ignored (output = 0), but in my teste is the reset event that is been ignored. Could your confirm that?

[mikael239955_stm1_st]

Posted on November 27, 2015 at 17:44

> on page 643 of the RM0364 it is written:

> ''

If the set and reset events are generated within the same

t

HRTIM

period, the reset event has

the highest priority and the set event is ignored.''

   > So, in my understand if the CMP1 <= 32, The Set and Reset events occurs in the same tHRTIM period,> the first one after timer reloads, so the set event should be ignored (output = 0), but in my teste is the> reset event that is been ignored. Could your confirm that?Nope,  because you are referring your initial problem to the wrong ref manual text.As you already said, you are using PER and CMP1 and nothing else as set/reset source while the text you refer tois the description of arbitrating among many set/reset sources , something the HRTIM can do to create multiwaveforms. You are not creating a multi waveform just a single PWM pulse.Read page 642 and contemplate, page 643 is just the diagram.Page 629 gives more info on how the crossbar works.

[Asantos]

Posted on December 01, 2015 at 15:21

Hi,

 I did some more tests: If Output is set on CMP1 and Reset on CMP2. If CMP1 = CMP2 =32 => Output = 0. Ok. but if CMP1 = CMP2 = 0 => Output = 1. Bad.   ST could do better! Ari.  

[danilo2]

Posted on March 08, 2016 at 23:54I am having the same problem. Also if I stop the output and turn it on again the first pulse is not aligned with the set of the period, strangely it starts right away although I am using preload registers, etc.I have blown some mosfets because of this, thanks for sharing your problem, I will try to find a workaround.

[SwineOne]

Posted on November 23, 2016 at 11:57

I just came across the exact same problem.

After sifting through the reference manual for this part, I came across Table 82 in Section 21.3.4 (page 623). There it is made clear that there are minimum and maximum values for the period and compare registers, just as stated in another post in the thread (though the post in question doesn't make it clear whether it was official ST info or something discovered by the poster -- I'm now adding the reference). While I agree that it's very dangerous behavior to go from near 0% duty cycle to 100%, on the other hand, according to the table mentioned above, you are indeed working outside spec, so you can't expect the part to behave reliably in this case.The solution, as I see it, is to clamp values in software to the range inside the spec. The problem is you won't get true 0% duty cycle output, but a very narrow pulse. If this is something you need, then you'll have to find a register in HRTIM that forces the pin low when 0% duty cycle is called for.However this is not bad behavior, just a question of running the part out of spec. However, I have to say that the documentation could make this a bit clearer, it took me a day of searching to realize this.

[jose luu]

Posted on November 02, 2017 at 17:07

I ran into this problem today. Here are some more observations:

Going under the value 0x60 is not recommended as per documentation, above 0x60, one get time increases of about 250ps per unit as expected. If one does under 0x60, the next usable value is 0x40, ie any value in between (0x41 and 0x60) has the effect of 0x60 (ie 25ns pulse width), the next step below is 0x20 (about 9ns), then going to 0 as you reported it goes to full active (100%). Not a safe behavior indeed, garanteed to burn some mosfets if one does not implement a workaround.

I tried Ari's workaround using a second comparator as a basis, but unfortunately it did not work, ie I still get the previous behavior with values shifted by 0x60 (ie 100% duty cycle with 0x60, the first step (9ns pulse wiidth) being at 0x80, etc.  May be I was not in the same counter mode.

I did a workaround using software, that is anytime I need a value under 0x60, I stop the timer and force the output state to inactive, anytime I need above, I restart the timer. This makes a crude software based PWM using the minimum pulse width. The output becomes much noisier, I suppose I should do some software filtering, but since we are not supposed to operate much in this area I will leave it this way. I did the same near period value. Let's call it 'limping mode'.

Code is here:

https://gist.github.com/joseluu/fbc0281ecd5ef343ebc65a5da732e142