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.
Dear Champs,
I am asking this for our customer.
1. In TRM 20.15 HRPWM,
in the doc, are below terms mean the same thing?
micro-edge positioner (MEP) step
HRMSTEP register
MEP_ScaleFactor
2. When we say, the resolution is 150 ps typically, it means one MEP step.
CMPAHR = 1 means 1/256 coarse step (clock cycle)
HRMSTEP = 1 means 150 ps (typically)
Therefore, CMPAHR = 1, 2, 3 may result in HRMSTEP = 1 => 1 step of 150 ps.
Is our understanding correct?
Hi Wayne,
To answer question 1:
The MEP step is the smallest possible HRPWM step. The typical value of this is 150 ps, but it fluctuates based on the device's environment.
The MEP_ScaleFactor is the number of MEP steps per TBCLK. This value is calculated by the SFO library and written to the HRMSTEP register.
CMPAHR is the number of MEP steps added to the CMPA value.
When auto-conversion is enabled, CMPAHR and HRMSTEP are used together in hardware to produce the delay desired by the user as accurately as possible.
For example, if CMPAHR is 2 and the device is in normal conditions(MEP step = 150 ns), the EPWM module will use two MEP steps to produce the delay desired by the user.
However, if the device is not under normal operating conditions, causing the MEP step to become 75 ns, the EPWM module will use FOUR MEP steps, since the user requests a 300 ns delay via the CMPAHR register.
This behavior only occurs if auto-conversion is enabled. If auto-conversion is disabled, the number of MEP steps used in hardware will always be equal to CMPAHR.
Let me know if this answers your question.
Dear Luke,
The user has further questions:
1. If auto conversion is enabled and SFO is not used, does that mean there is no HRMSTEP update and HRSTEP is always 0. In this case, no matter what value CMPAHR is assigned, HRPWM does not take effect. Is it right?
2. If auto conversion is disabled and SFO is not used, MEP steps used in hardware is equal to CMPAHR. Is it right?
3. If the user unexpected assign a CMPAHR larger than MEP_ScaleFactor, what will happen? Will it saturate to MEP_SacleFactor or will it place MEP beyond that course step (that clock cycle) and onto the adjacent course step (adjacent clock cycle)?
Hi Wayne,
1. If auto conversion is enabled and SFO is not used, then I believe the default value(0) in the HRMSTEP register will be used. The SFO library should always be used whenever auto-conversion is enabled.
2. This is correct
3. If auto-conversion is enabled and the SFO library is being used, then the number of MEP steps will be calculated by hardware so that the CMPA event is delayed by a time equal to (CMPAHR * typical MEP step duration). For example, if the SFO library calculates HRMSTEP to be half of the typical value, and CMPAHR is 200, then 100 MEP Steps will be used in hardware to produce the delay expected by the user under typical conditions.
Let me know if this answers your question.
--Luke
Dear Luke,
For question 3, the user is concerned if it possible for the user to accidentally assign a wrong CMPAHR, which is larger than the calculated MEP_ScaleFactor/HRMSTEP (SFO enabled/auto conversion is enabled)? And what will happen?
Hi Wayne,
When auto-conversion is enabled, CMPAHR can be any value from 0 to 255, regardless of the value of HRMSTEP. Say for example HRMSTEP is calculated to be 100 by the SFO library. This means there are 100 MEP steps per one coarse step. If CMPAHR is 128, then the delay calculated by hardware will be 1 TBCLK * (128/256). To produce this delay, 50 MEP steps will be used, since 50 MEP steps is equal to 1/2 of 1 coarse step, or 1/2 of 100 MEP Steps.
Note that this only applies if AUTO conversion is enabled. Are you asking what will happen if AUTO conversion is disabled? In that case, the user should make sure their CMPAHR value is always less than the MEP_ScaleFactor. Let me know if the customer wishes to know what happens if CMPAHR is larger than HRMSTEP/MEP_ScaleFactor in this case and I can request this information.
Thank you,
Luke
Dear Luke,
Yes, the user wonders when AUTO conversion is disabled what happens if CMPAHR is larger than HRMSTEP/MEP_ScaleFactor?
Hi Wayne,
My assumption is that the CMPA event would take place after the beginning of the next cycle, since the TRM states that the HRMSTEP register is ignored when auto-conversion is disabled. I will need some time to confirm this.
We have specific procedures outlined in the TRM for calculating CMPAHR in section "20.15.1.5.2 Scaling Considerations"
Can you confirm the customer wants to use auto-conversion in their application? Do they just want this information for the sake of better understanding HRPWM?
Thank you,
Luke
Dear Luke,
Can you confirm the customer wants to use auto-conversion in their application?
[W] They can use auto-conversion only if this really benefits them. We strongly recommend that they enable auto-conversion and SFO. Is it right?
Do they just want this information for the sake of better understanding HRPWM?
[W] Yes.
Hi Wayne,
We always recommend using auto-conversion and the SFO library when using HRPWM. When using high-resolution period control, it is required to use auto-conversion. Using auto-conversion also eliminates the risk of calculating an invalid CMPAHR value since all values between 0 and 255 are valid, and only the upper 8 bits of the CMPAHR register are used.