CPU2 access to ePWM CMPA/BHR

Hi,

I understand that SFO() can only be run by CPU1 (likely because it requires access to those config registers). I believe, based on previous threads, that SFO() uses ePWM1 to perform its calibration, and then finishes by updating all other channels with the new HRMSTEP value. So any channels owned by CPU2 would not be updated by SFO(). But it might be possible for the user application to transfer the HRMSTEP value from ePWM1 to the CPU2-owned channels, thereby resolving the issue, correct?

Yes, the SFO() uses EPWM1 to perform its calibration and updates respective HRMSTEP register and MEP_ScaleFactor variable with the result.  The resultant MEP_ScaleFactor value can be tranferred to CPU2 through shared RAMs etc. to update the HRMSTEP value for EPWMs owned by CPU2. 

Thanks

Vasudha

Mike Twieg said:

I'm aware that TI recommends that only CPU1 make use of HRPWM. But other threads (especially this one) suggest that the limitation is only with regards to specific registers (HRCNFG, HRCONFIG2, etc) which must be done by CPU1. In many cases, once those registers are configured, only the high resolution extensions of CMPA/CMPB/FED/RED would need to be accessed. I want to know if CPU2 can write those registers if it is given ownership of the ePWM channel.

Yes, as per the mentioned thread, only the initial HR related configuration needs to be done in CPU1 after which the EPWMx ownership should be passed to CPU2. There after HR extensions of CMPA/CMPB/FED/RED can be accessed through CPU2.

Thanks

Vasudha

Thanks for the reply Vasudha,

But now I'm a bit confused, because I also just recalled other e2e threads in which it was suggested that HRMSTEP only needs to be written in ePWM1, and is somehow shared with ePWM2-8 automatically via some unknown mechanism. Could you clarify which is the truth?

Putting that aside for a moment, I've seen numerous other threads expressing concern about how SFO() might interfere with fast control loop code, but I've never seen anyone propose this workaround. Seems like it would fully decouple the execution of SFO() from the fast code, with the following limitations:

1. CPU1 should always have ownership of ePWM1. Therefore the PWM controller code on CPU2 should not rely on ePWM1. In my application, ePWM1 is set up to be a fixed period/duty cycle, in order to act as a SYNC source for other ePWM channels which actually require HR duty cycle modulation. I assume this is fine?

2. After SFO() completes, MEP_ScaleFactor needs to be manually copied to HRMSTEP on the CPU2-owned ePWM channels. Instantiating MEP_ScaleFactor in a shared RAM block would help this.

Hi,

There are few HR registers which are only available in EPWM1. The documentation is not clear on this.I will check if HRMSTEP is also one of them and get back.

Thanks

Vasudha

Hi Vasudha, any update on this?

Hi,

The HRMSTEP register updated by SFO can be accessed by all the other HRPWM instances even when it is owned by other CPU. Hence in case the autoconvert is ON then there is no need to pass the step value from CPU1 to CPU2. If the autoconvert is OFF then the MEP_ScaleFactor variable updated by the SFO lib needs to be passed from CPU1 to CPU2. This can be done through IPC in the application.

Thanks

Vasudha

Thanks Vasudha,

In my case auto conversion is ON, so SFO() executed on CPU1 will update all PWM channels, so long as PWM1 is owned by CPU1, I suppose. Other than that, is there any potential for interaction between SFO() and the other PWM channels? Like blocking CPU2/CLA access to the CMPA/CMPB HR registers?

Also you mentioned this before:

"There are few HR registers which are only available in EPWM1"

Did you mean "CPU1" instead of "EPWM1"? Could you provide a full list of such registers?

Regards,

Mike

Hi,

I am checking up on the list of registers and will get back shortly.

Thanks

Vasudha

Hi Mike,

Due to the US Holiday, please expect a reply early next week.

Best Regards,

Marlyn

Hi Vasudha or Marlyn, could you please give me an update??