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.

TMS320F280023: Use of shadow registers for HRPWM with > 1MHz

Part Number: TMS320F280023
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hello

We need to configure the HRPWM of the TMS320F280023 for a flyback converter. We want to avoid any glitch in period or duty cycle while the PWM is running. The frequency can be >1MHz which does not allow any software controlled synchronisation to update period and duty cycle.  We concluded, that the only way is to use shadow registers. But it certainly needs some time to update all shadow registers and we want to prevent that there is any transfer to active registers before the software has written a vaild set of data to all shadow registers. For a simultanous and well controlled transfer of all shadow regsiters (period, HR period and duty and HR duty) to active registers we found that the one shot global load should be the right way to do.  But there seems to be a problem.

We tried global one shot option to update period, HR period , duty and HR duty simultaneously by writing 1 to GLDCTL2(OSHTLD) only after all shadow registers have been updated by the software. So far it looks like it is working but we discovered the following NOTE: "One-shot load mode must not be used when high-resolution mode is enabled." (SPRUINN7C, page 1790). Now we are confused.

Question 1: Is it still possible to use global load but without one shot  instead ( GLDCTL(OSHTMODE=0) )? But this mnode loads active registers continously and we can't delay the shadow to active transfer until all shadow registers are written. How can we disable/enable the shadow to active transfer by software to guarantete that only a valid set of shadow register values are loaded to active registers? If this is not possible: what do you recommend as workaround?

Question 2: Is there any risk of a glich if the shadow registers are beeing updated at exactyl the same time when the hardware is transfering shadow to active? Or with other words: can it happen that a partially written shadow register content is transfered to active registers like period, HR period, duty and HR duty? 

We hope for a clear answer that helps to solve our problem. Many thanks in advance for your valuable support.

Best regards

Daniewl Keller

  • Global loading is required in case you want to update more than one PWM module. In case of updating in parameters in one module shadow loading is good enough. Are you using more than one ePWM module for flyback converter?

    Regards,

    Sumit

  • Thanks. We are not using multiple PWM. But we wanted to update all paramters (HRDuty AND HRPeriod) simultanously. As an update of HR duty and period includes writing multiple shadow regsister it may happen that the shadow to active occurs while we are writing those registers. This may result and inclomplete update: parameters which have been written to the shadow just slightly after counter zero will be updated only with the next pwm cycle.  So we can have a partiall update with some paramters with the first PWM cycle and the rest of the paramters are updated with the next PWM cycle. This is not fully synchrounous but we can handle it if there is no other solution.

  • Daniel,

    If updating ISR frequency is equal to FSW=1MHz then updating in shadow load mode should not be the issue.

    But if you are using ISR < FSW=1MHz. If yes, then in that case you can implement logic to monitor to see if TBCTR is far away from reaching zero, you can raise flag in that case to start writing in shadow register if that case is not true then wait for next ISR cycle and condition to raise the flag. 

    You can refer this e2e as well for your reference: e2e.ti.com/.../tms320f280049c-is-shadow-to-active-load-disabled-during-shadow-write-access

    Let me know if that makes sense.

    Regards,

    Sumit

  • Sumit,

    Yes, this makles sense. We have an ISR which updates the PWM parameters every 1ms. The PWM period is in the range 0.7 - 2us. We will check if we can make some software based syncronisation to write the shadwo registers as early as possible (right after counter reset)  to esure that everything is writen well before the next shadow to active transfer.

  • Daniel,

    Yes, that will be correct approach. Generally, when PWM is not in sync with ISR we recommend to prioritize control effort calculation and writing new values to these PWM registers only when TBCNR is far away from zero. By implementing this way, control associated delay can be minimize along with guaranteed writing all shadow register so that everything is written well before the next shadow to active transfer.

    Let us know you encounter any further issue.

    Regards,

    Sumit

  • Sumit,

    Thanks, it all makes sense and we will work on this solution.

    Meanwhile we discovered another confusing problem. We configured the PWM as HRPWM with up-count mode without deadband. We use HRmode for duty and period. We respect the HR mode specific restrictions:  minimum duty > 3 clk and maximum duty < (period - 3CLK).

    We set the action qualifier as follows: "set Hi on Period" and "Clear Low on CMPA" and "Do nothing at ZERO". For turning the PWM outputs ON and OFF without any glitches, we simply change between "set Hi on Period" to "Clear Lo on Period". So far this works well and we thought everything is OK. But later we found the comment in 17.6.5 on age 1803 in SPRUINC7C (marked in red) :

    When using up-count mode to generate an asymmetric PWM:
    • To achieve 0-100% asymmetric PWM, you must load CMPA/CMPB on TBPRD. When CMPA/
    CMPB is not loaded on TBCTR=PRD, boundary conditions can occur depending on the timing
    of the write and the value written to CMPA/CMPB. Use the Zero action to set the PWM and a
    compare-up action to clear the PWM. Modulate the compare value from 0 to TBPRD+1 to achieve
    0-100% PWM duty.

    And figure 17-27 showed set Hi on Zero as well.

    So we changed to: "set Hi on Zero",  "Clear Low on CMPA" and "Do nothing on PERIOD" according fig. 17-27.  But the HRPWM did not work properly anymore. The timing got irregular, without sub clock resolution but the duty jittered by 1 counter CLK. After changing back to Set Hi on Period,  it worked again properly. 

    Can you explain this? Is this comment not valid for HRPWM mode? Did we misunderstood the note 17.6.5 and fig. 17-27 or can it be that we made a mistake with the initialisation or the way we opreate the HRPWM?

  • Daniel.

    The note says in TRM is recommended operation to achieve full range of duty control. You can refer the following example shows its implementation especially for up-mode counter. You can see its .sysconfig file for the configuration it has done for your case and match with your configuration. I will recommend you to check every tab of this example to see if there is any difference with your code and try to fix it.

    Regards,

    Sumit

  • Sumit,

    Thank you very much for this hint. We will check it. 

    No other questiosn right now. Your support has been much appreciated!

    Daniel

  • Daniel,

    You are welcome. I will close this thread for now. Please feel free to reach out to us if any issue on this in future.

    Regards,

    Sumit