This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F280039C-Q1: HRPWM implementation

Part Number: TMS320F280039C-Q1

Hi all,

we are currently implementing HRPWM. To do this we encountered the following comment in the TRM (page 2168)



How can we make sure that the HRPWMs start / stop at the same time and change frequency at the same time if the One-Shot Mode cannot be used?What is the reason for this limitation?

Does this generally apply to all registers? Or is it just a limitation for the HR register where we cannot use the one-shot mode e.g. period, dead band, etc.? It means, is it possible that set e.g. the Action Qualifier and SW-Force with One-Shot Load?

Thanks

Jens

  • Hi Jens,

    Are you familiar with the EPWMXLINK feature? It allows for simultaneous updates to CMPx or GLDCTL2 across EPWM modules by writing to the register of a single module. Is it possibile to use EPWMXLINK in your application instead of one-shot global load?

    I am not aware of the reason for this limitation at the moment, I will consult with our other EPWM experts to determine this. I would assume this note applies for all registers when HRPWM is enabled but I will get clarification on this as well.

  • Hi Jens,

    Unfortunately we do not have a formal history of why this note was added. We consulted with the design team and they are not familiar with any risks associated with using one-shot global load with HRPWM. However one of our EPWM experts Cody Watkins provided the following feedback on why this note may have been added:

    "My suspicion is that it will update, well once, and then disable the loading. This would be an issue if you had an HR shift applied to the rising and falling edge in up-down count mode. The first edge would load the HR values for the rising edgen, then I assume even if the load events have  been set to “load on zro and PRD’ then the one shot logic would block the CTR=PRD load event meaning that the falling edge HR values would never load and the pulse width would be wrong. Probably not horribly wrong because its only the HR portion, but still not correct.”

    Let me know if you have any concerns with the behavior described above in your application, or if you are able to observe it while testing your application.

    Thank you,

    Luke