• State Resolved
  • Locked Locked
  • Replies 31 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 3850 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28075: HRPWM anomaly under certain conditions

Pierre Bouchet1
Expert 2575 points
Part Number: TMS320F28075
Other Parts Discussed in Thread: TMS320F28035

Hi everyone,

I'm encountering a problem with HRPWM similar to the one mentioned in this topic. I have seen it occur both on TMS320F28035 (ePWM Type 1) and TMS320F28075 (ePwm Type 4).

The problem manifests itself as an unwanted glitch on the PWM output. In the actual application I use many peripherals such as the ADC, ECAP, ECAN, SPI, CPU timers and interrupts, CLA, etc. but I took some time to find the smallest possible code which allows me to reproduce the problem, which seems to only involve the ePWM peripherals.

The oscilloscope screenshot below shows the glitch. It is achieved with a small program running on the TMS320F28035 controlCARD.

The yellow signal is EPWM1A on GPIO0. The blue signal is a reference signal generated using EPWM2A with edges configured for events CTR=PRD and CTR=ZRO.

First a few notes on things I have tried:

  • The ePWM period (TBPRD) and clock speed (TBCTL[CLKDIV] and TBCTL[HSPCLKDIV]) do not seem to have any influence on the problem.
  • I have tried with and without using the autoconversion feature, it doesn't seem to change anything to the problem.
  • I have tried with and without the background calibration of the MEP using the SFO() function and doesn't seem to change anything to the problem.
  • I have tried using the internal oscillator and an external quartz but it doesn't change anything to the problem.

The code used to reproduce the problem is the following:

EALLOW;
SysCtrlRegs.PCLKCR1.bit.EPWM1ENCLK = 1;
SysCtrlRegs.PCLKCR0.bit.HRPWMENCLK = 1;

EPwm1Regs.TBCTL.bit.CTRMODE = 2;
EPwm1Regs.AQCTLA.bit.CAU = 1;
EPwm1Regs.AQCTLA.bit.CAD = 2;
EPwm1Regs.TBPRD = 200;
EPwm1Regs.CMPA.half.CMPA = 50;
EPwm1Regs.CMPCTL.bit.LOADAMODE = 1;		// load on CTR = PRD
EPwm1Regs.HRPWR.bit.MEPOFF = 0;
EPwm1Regs.HRCNFG.bit.EDGMODE = 2;
EPwm1Regs.HRCNFG.bit.HRLOAD = 1;		// load on CTR = PRD

GpioCtrlRegs.GPAMUX1.bit.GPIO0 = 1;
SysCtrlRegs.PCLKCR0.bit.TBCLKSYNC = 1;
EDIS;

for (;;) {
	DELAY_US(10);
	EPwm1Regs.CMPA.half.CMPAHR = 0;
	DELAY_US(10);
	EPwm1Regs.CMPA.half.CMPAHR = (200U << 8);
}

All this program does is switch CMPAHR between zero and a non-zero value.

The problem only seems to appear when the ePWM is running in up-down count (TBCTL[CTRMODE] = 2) AND the micro-edge position logic controls the falling edge (HRCNFG[EDGMODE] = 2) AND the CMPAHR load event is programmed outside of the pulse (when the PWM signal is at 0).

This last condition is because I have seen the problem in two configurations:

  1. Pulses centered on CTR=ZRO (AQCTLA[CAU] = 1 / AQCTLA[CAD] = 2 / HRCNFG[HRLOAD] = 1)
  2. Pulses centered on CTR=PRD (AQCTLA[CAU] = 2 / AQCTLA[CAD] = 1 / HRCNFG[HRLOAD] = 0)

Furthermore the width of the glitch seems to be related to the value of CMPAHR, as shown by the two pictures below. The first one is with CMPAHR set to 130 steps and the second one with CMPAHR set to 230 steps.

 

 

That is all the information I have for now, but if you need to know anything else please let me know.

Cheers,

Pierre

  • 0
    TI__Guru 52010 points

    Pierre, I would like to look into this. Can you send the CCS project so I have everything matching your setup?

    Nima

  • 0 in reply to Nima Eskandari
    Expert 2575 points

    Hi Nima,

    Please find attached the CCS project.HRPWM_GLITCH.zip

  • 0 in reply to Pierre Bouchet1
    TI__Guru 52010 points
    Thank you,

    I'm going to tests this on F28379D control card since we no longer manufacture the f28075 control card.

    Nima
  • 0 in reply to Nima Eskandari
    Expert 2575 points
    Nima,

    This is an F28035 project, I run it on the F28035 controlCARD, not the F28075 one.

    Pierre
  • 0 in reply to Pierre Bouchet1
    TI__Guru 52010 points
    I see that the EPWM loads the shadow regs on CTR=ZERO while the HRPWM loads on both CTR=ZERO and CTR=PRD. Can you try this code with both EPWM and HRPWM loads to occur at CTR=ZERO?
  • 0 in reply to Nima Eskandari
    Expert 2575 points

    Hi Nima,

    I tried with the following configuration:

    EPwm1Regs.TBCTL.bit.CTRMODE = 2;
EPwm1Regs.AQCTLA.bit.CAU = 1;
EPwm1Regs.AQCTLA.bit.CAD = 2;
EPwm1Regs.TBPRD = 200;
EPwm1Regs.CMPA.half.CMPA = 50;
EPwm1Regs.CMPCTL.bit.LOADAMODE = 0;		// load on CTR = ZRO
EPwm1Regs.HRPWR.bit.MEPOFF = 0;
EPwm1Regs.HRCNFG.bit.EDGMODE = 2;
EPwm1Regs.HRCNFG.bit.HRLOAD = 0;		// load on CTR = ZRO

    The result is that there is no glitch.

    On the other hand the next configuration results in the glitch appearing:

    EPwm1Regs.TBCTL.bit.CTRMODE = 2;
EPwm1Regs.AQCTLA.bit.CAU = 1;
EPwm1Regs.AQCTLA.bit.CAD = 2;
EPwm1Regs.TBPRD = 200;
EPwm1Regs.CMPA.half.CMPA = 50;
EPwm1Regs.CMPCTL.bit.LOADAMODE = 0;		// load on CTR = ZRO
EPwm1Regs.HRPWR.bit.MEPOFF = 0;
EPwm1Regs.HRCNFG.bit.EDGMODE = 2;
EPwm1Regs.HRCNFG.bit.HRLOAD = 1;		// load on CTR = PRD

  • 0 in reply to Pierre Bouchet1
    Expert 2575 points

    Nima,

    Please see the following table summarizing the different behaviours I can observe on my F28035 controlCARD.

    AQCTLA[CAU]/AQCTLA[CAD] CMPCTL[LOADAMODE] HRCNFG[HRLOAD] Observed behaviour
    Clear (1) / Set (2) Load on CTR = PRD (1) Load on CTR = PRD (1) ANOMALY
    Clear (1) / Set (2) Load on CTR = PRD (1) Load on CTR = ZRO (0) ok
    Clear (1) / Set (2) Load on CTR = ZRO (0) Load on CTR = PRD (1) ANOMALY
    Clear (1) / Set (2) Load on CTR = ZRO (0) Load on CTR = ZRO (0) ok
    Set (2) / Clear (1) Load on CTR = PRD (1) Load on CTR = PRD (1) ok
    Set (2) / Clear (1) Load on CTR = PRD (1) Load on CTR = ZRO (0) ANOMALY
    Set (2) / Clear (1) Load on CTR = ZRO (0) Load on CTR = PRD (1) ok
    Set (2) / Clear (1) Load on CTR = ZRO (0) Load on CTR = ZRO (0) ANOMALY

    Were you able to reproduce this?

    Cheers,

    Pierre

  • 0 in reply to Pierre Bouchet1
    TI__Guru 52010 points

    Yes I have tried some of the conditions and I do the see the unwanted pulse. For now could you continue your work with one of the working conditions while I investigate the issue? I suspect this is a know condition which could be documented.

  • 0 in reply to Nima Eskandari
    Expert 2575 points

    Nima,

    Yes I have been using one of the working conditions as a workaround for some time now.

    These unwanted pulses can cause a lot of damage when they induce cross-conduction.

    Regards,

    Pierre

  • 0 in reply to Nima Eskandari
    Expert 2575 points
    Hello Nima,

    Did you make any progress in your investigation?

    Cheers,
    Pierre
  • 0 in reply to Pierre Bouchet1
    TI__Guru 52010 points
    Still in progress. I will post the results once completed.
  • 0 in reply to Nima Eskandari
    TI__Guru 52010 points

    Can you try something and let me know what results you get?

    Can you set the rest of the actions? For example when they are not needed, set them to no action or to the actual state they need to be.

    // Action qualifier register bit definitions */
AQCTL
   ZRO              // 1:0    Action Counter = Zero
   PRD              // 3:2    Action Counter = Period
   CAU              // 5:4    Action Counter = Compare A up
   CAD              // 7:6    Action Counter = Compare A down
   CBU              // 9:8    Action Counter = Compare B up
   CBD              // 11:10  Action Counter = Compare B down

    Mainly i'm concerned with ZRO AND PRD. Try setting those to no action or PULL high or low when needed.

  • 0 in reply to Nima Eskandari
    TI__Guru 52010 points
    Okay We found the issue.

    The issue is with HRMSTEP. You do not have AUTOCONV enabled and are not running SFO to calibrate HRPWM. This determines element delay and how many elements fit in a SYSCLK period. If more elements are selected, that edge which getting delayed by propagating through the elements is going to occur at an unwanted location.

    You can simply turn on AUTOCONV as a quick fix. but please take some time to read through
    www.ti.com/.../spruge8e.pdf

    And take a look at our example codes in
    http://dev.ti.com/tirex/#/

    Thank you for your patience.
  • 0 in reply to Nima Eskandari
    Expert 2575 points

    Nima,

    I've been using the HRPWM for six years, I know that datasheet very well. Please pay attention to my first message:

    • I have tried with and without using the autoconversion feature, it doesn't seem to change anything to the problem.
    • I have tried with and without the background calibration of the MEP using the SFO() function and doesn't seem to change anything to the problem.


    I am going to run the code I sent you with the autoconv and SFO and send you oscilloscope pictures so you can see for yourself.

    Pierre

  • 0 in reply to Nima Eskandari
    Expert 2575 points

    Nima,

    1. I cannot find any example codes with the HRPWM used for duty control in up-down count mode. Where are they?
    2. Please find attached a small CCS project with all the features you asked: AUTOCONV, SFO and all unused events set to zero (no action) as you asked.
    3. You can see in the oscilloscope capture that the anomaly is still present. HRPWM_GLITCH_2.zip

    Cheers,

    Pierre

  • 0 in reply to Pierre Bouchet1
    TI__Guru 52010 points

    Pierre,

    I'm confused. I tried the code you sent me with AUTOCONV enabled and the anomoly was not present. I'm gonna try again and share the results.

    Nima

  • 0 in reply to Nima Eskandari
    Expert 2575 points
    Nima,

    Did you make any progress to reproduce the anomaly?

    Pierre
  • 0 in reply to Pierre Bouchet1
    TI__Guru 52010 points

    Yes here is the code with AUTOCONV and the screenshot of the scope without the anomaly.

    void main(void) {
	initClock();
	initFlash();

	__eallow();
	SysCtrlRegs.PCLKCR1.bit.EPWM1ENCLK = 1;
	SysCtrlRegs.PCLKCR0.bit.HRPWMENCLK = 1;

	EPwm1Regs.TBCTL.bit.CTRMODE = 2;
    EPwm1Regs.AQCTLA.bit.CAU = 1;
    EPwm1Regs.AQCTLA.bit.CAD = 2;
	EPwm1Regs.TBPRD = 200;
	EPwm1Regs.CMPA.half.CMPA = 50;
    EPwm1Regs.CMPCTL.bit.SHDWAMODE = 0;     // Shadow mode
	EPwm1Regs.CMPCTL.bit.LOADAMODE = 2;		// load on CTR = PRD
	EPwm1Regs.HRPWR.bit.MEPOFF = 0;
    EPwm1Regs.HRCNFG.bit.EDGMODE = 2;
    EPwm1Regs.HRCNFG.bit.AUTOCONV = 1;
	EPwm1Regs.HRCNFG.bit.HRLOAD = 1;		// load on CTR = PRD

	GpioCtrlRegs.GPAMUX1.bit.GPIO0 = 1;
	SysCtrlRegs.PCLKCR0.bit.TBCLKSYNC = 1;
	__edis();

	for (;;) {
		DELAY_US(10);
		EPwm1Regs.CMPA.half.CMPAHR = 0;
		DELAY_US(10);
		EPwm1Regs.CMPA.half.CMPAHR = (220U << 8);
	}
}

    I have also take out the AUTOCON to show how the issue is caused by not using AUTOCONV nor the MEP_SFO library.

  • 0 in reply to Nima Eskandari
    Expert 2575 points

    Nima,

    When I explained my problem you asked me to send you my CCS project, which I did. If you think you have demonstrated that the anomaly has disappeared then please send me your whole project, not just a code snippet.

    Until now I'm still convinced that the anomaly occurs even with the AUTOCONV enabled. I'm beginning to suspect that maybe there are difference between our setups. Which part are using? Is it a TMS320F28035 ? If yes is it on a controlCARD ? Are you running the exact code I sent you or did you write your own CCS project?

    Furthermore what is the bandwidth of your oscilloscope?

    Pierre

  • 0 in reply to Pierre Bouchet1
    TI__Guru 52010 points

    Pierre,

    I have attached the CCS project. autoconv.zip

    I am using a F28035 control card on a docking station.I'm using a 100MHz, 1GSamples/s scope.  

  • 0 in reply to Nima Eskandari
    Expert 2575 points

    Thanks! I'll try it again tomorrow. I have basically the same hardware as you.

    Pierre

  • 0 in reply to Pierre Bouchet1
    TI__Guru 52010 points
    Any update on this? I'm curious how we could have different results on this type of matter when we are using the same Control Card and setup with the same code.

    Please let me know as soon as you run the code so we can compare notes again.
  • 0 in reply to Nima Eskandari
    TI__Guru 52010 points
    Pierre,

    I'm checking in to see if your problem was solved using the example CCS project I sent you. Please let me know if the issue still exists.

    Nima
  • 0 in reply to Nima Eskandari
    Expert 2575 points
    Nima,

    I haven't had the time to test yet. I'll keep you posted.

    Pierre
  • 0 in reply to Pierre Bouchet1
    Expert 2575 points
    Nima,

    I have tested once again the project I sent you as HRPWM_GLITCH_2.zip and once again I can confirm that the anomaly is present. Are you certain you are running it without changing anything?

    I also tested the project you sent. You need to review it because your code never writes a scale factor to the HRMSTEP register so the auto-conversion will always result in a zero value. Therefore the HRPWM can never work properly in this example. See Table 7 in datasheet SPRUGE8E.

    I have a new idea about what the problem could be but I need to test a few more things. Can you correct your code and test it again?

    Pierre
  • 0 in reply to Nima Eskandari
    Expert 2575 points
    Nima,

    Have you found the time to run the example project again with proper initialization of the HRMSTEP register?

    Pierre
  • 0 in reply to Pierre Bouchet1
    TI__Guru 52010 points
    Pierre,

    The first and very important thing that I found is that the HRCNFG must be configured to load on both CTR=0 and PRD when in up-down mode.
    According to this:
    e2e.ti.com/.../2558177

    Nima
  • 0 in reply to Nima Eskandari
    Expert 2575 points
    Nima,

    I read this message but as I explained in previous messages the anomaly shows up when in this configuration. However I'm in a special case as I use the HRPWM in up-down mode not for period control but for duty control.
  • 0 in reply to Pierre Bouchet1
    TI__Guru 52010 points

    Pierre,

    What frequency is the device running at? Also the EPWMCLK?

    Here is what I was looking at in the lab:

    1. We have to keep the CMPAHR value below the maximum number of MEP steps per coarse step (Not using auto-convert )
    2. When we are in Up-down mode, the HRPWM load must occur on both CTR=0 and PRD.

    When I use values below 115 for CMPAHR I see that the anomaly doesn't happen.

    I'm going to ask our systems team to help with this. Because I believe the number of MEP steps is much larger than 115 so we should be able to use larger values.

  • 0 in reply to Pierre Bouchet1
    TI__Genius 10820 points

    Hello Pierre,

    I just went through this post and I believe I have an explanation and a solution (although you've already found/implemented it).

    The key piece in your configuration is that HR edge control is only applied to the falling edge (EDGMODE = 2).

    When AQ settings 'Set' the output on a CAD match and reset the outputs on a 'CAU' match, the falling edge occurs when the counter is counting up. As a result the HRLOAD should be configured to load on 0. I would also select LOADAMODE = 0 to keep all values synchronized for that cycle, but this is not a necessary condition.

    Similarly, when AQ settings 'Set' the output on a CAU match and reset the outputs on a 'CAD' match, the falling edge occurs when the counter is counting down. As a result the HRLOAD should be configured to load on PRD. LOADAMODE could be PRD or 0 based on your control requirements.

    HRLOAD should be selected to load on both 0 or PRD, when HR edge control is applied to both rising and falling edges (EDGMODE = 3).

    I hope this helps.

    Hrishi

  • 0 in reply to Hrishi Nene
    Expert 2575 points

    Hello Hrishi,

    Indeed I try to keep the values synchronized because it seems logical to have CMPA and CMPAHR updated at the same time. 

    However in this case it's precisely how the anomaly appears: as soon as I try to synchronize the values it shows up.

    The workaround I have been applying, i.e not synchronizing the values, allows me to have something that works. The update of CMPA needs to occur before the next rising edge whereas the update of CMPAHR only needs to occur before the next falling edge.

    I still have no idea why the anomaly occurs but I think your message is a confirmation that my workaround should be effective. Could you take a look at the diagram attached to this message and confirm my understanding is correct? 

    Cheers,

    Pierre