Change PWM polarity at update event with STM32 Timers?

[SJung.1899]

I am using the adanced control and the general purpose timers witch the STM32F334K8T6 to drive one half-bridge and one full-bridge.

The problem lies with the full bridge:

I use the general purpose timer with two times asymmetrical PWM (center aligned mode) which gives me a lot of freedom. Period and all Duty-Cycles are preloaded and always refreshed at the update event. However, I would like to change polarity of the two signals on an update event, too. I can change polarity but what is the best way changing it at the right moment (when the update event occurs).

If I am not mistaken there is no hardware solution for this. What do you propose? Should i poll the counter value or do it by some kind of intterupt? Periods are comparably short (10us), so an update event occurs every 5us.

I hope that the attached figure helps you to understand what I mean.

Thanks in advance,

Samuel

[waclawek.jan]

Probably the easiest is to set up a DMA triggered by the update, to write the required value into TIMx_CCER.

There will be a lag of a couple of system clocks between the update and the actual polarity change, given by the DMA operation.

JW

[SJung.1899]

Thanks a lot, this works just fine. The lag is very small when the priority of the DMA transfer is high. This is probably the most elegant way of doing it.

Samuel

[SJung.1899]

However, there is one further problem that I have noticed now. The polarity change happens later than expected.

I start the DMA in circular mode with a data length of 1.

HAL_DMA_Start_IT(&HalfBridge_DMAHandle, (uint32_t) &HalfBridge_CCER_Temp,(uint32_t) &HalfBridge_Capture_Compare_Enable_Register, 1);

I write new Data to the variable HalfBridge_CCER_Temp, but at the next DMA transfer, the old data is transferred. At the next update event the desired polarity change occurs rapidly. I have a attached a measurement to make things more clear. Do you have any idea, what could be the problem or what I am missing?

[waclawek.jan]

Very interesting.

Most probably, the issue is caused by DMA buffering on the memory port.

I'm not sure what would be the best workaround, in case you can't bring writing new data more forward. You can try to swap the memory and peripheral ports (ie. write the buffer-in-memory address to DMA_CPARx and the TIMx_CCER address to DMA_CMARx; or you can stop/start the DMA when the value changes (you maybe don't need to have circular DMA anyway, so then you'd need just enable DMA).

Unfortunately, this issue is not explained in AN2548.

There's only one rather cryptic sentence at the end of 4.1.2, which says "opposite direction (peripheral to memory)" but the whole 4.1.2 (and 4.1.1) deals with peripheral-to-memory transfers. So, there's no discussion of memory-to-peripheral transfers, whatsoever.

@Imen DAHMEN​ , can AN2548 please be updated with detailed information on memory-to-peripheral transfers timing?

Thanks,

JW

[SJung.1899]

Thanks so much!

Indeed, changing the direction from memory_to_peripheral to peripheral_to_memory seemes to solve the problem. I was sure that this parameters was set correctly. However, now the value is transferred at the next update event.

Best regards,

Samuel

[Bubbles]

There was an refresh done recently on the AN2548, unfortunately before your inputs. We are already preparing more precise analysis of the timing for next release. I'm glad there is demand for this kind of information.

Thank you,

Jarda

[waclawek.jan]

How recently?

Freshly downloaded AN2548 shows me rev.6 9-May-2019 with only nominal changes (List of supported products extended to G0 and F3:)

(F3!~ sic! in 2019! wasn't it a thread here initiating that one, btw.?)

JW

@JHOUD​ 

[Bubbles]

Revision 7, May 2020, It's about two weeks.

[waclawek.jan]

Hi Jarda, ,

Thanks.

The pipes in ST's web appears to be clogged at times, e.g. https://community.st.com/s/question/0D53W000005oxMJSAY/where-is-an5094-migrating-between-stm32f334303-lines-and-stm32g474xxg431xx

Can you please try to flush this one through?

Thanks,

Jan

@JHOUD​