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.

TMS320F28035-EP: AQCSFRC register does not behave as expected

Part Number: TMS320F28035-EP


Tool/software:

I have a function which is supposed to turn off the PWM outputs via a continuous software force using the AQCSFRC registers.

#define         PWM_AB_OUTPUTS_OFF      0b0000000000000101

void Disable_PWM(void)
{
    //**********************************************
    // Force all PWM outputs off via continuous
    // software force. This takes effect on the next
    // rising edge of TBCLK (15MHZ) since we are 
    // immediate mode.
    //**********************************************

    DINT;
    EPwm1Regs.AQCSFRC.all = PWM_AB_OUTPUTS_OFF;         // force all ePWM1 outputs off
    EPwm2Regs.AQCSFRC.all = PWM_AB_OUTPUTS_OFF;         // force all ePWM2 outputs off
    EPwm3Regs.AQCSFRC.all = PWM_AB_OUTPUTS_OFF;         // force all ePWM3 outputs off
    EINT;
 }

I would expect that writing 0x0005 to this register would shut off both A and B outputs (force low) from the selected PWM channel(s), 1,2 and 3 in the code example. I would also expect this to work no matter what else is going on at the time with PWM. That is, even if I were to write to the normal action qualifier registers, changing PWM duty cycle, etc.

I am not writing the the AQSCFRC registers anywhere else in the code.

However, sometimes it works as expected, other times it does not.

Looking into the AQSCFRC registers after I call the Disable_PWM() function, I can see 0x0005 in  EPWM1 ,2, and 3.AQSCFRC registers. This should force both A and B outputs low for these PWM channels. But occasionally, after the function is called, I can see high currents with my power supply in current limit, so I know that PWM switches are on. Whether or not there is actually PWM occurring, I don't know. But I do know there are switches on that should not be on.

FYI - I am running the PWMs with IMMEDIATE reload. So the new settings should take effect on the rising edge of the next TBCLK cycle.

Here are my questions.

1. Are there any special conditions for using the continuous force register (AQSCFRC) ?

2. Does the requested force condition in this register override any other requested output action from the PWM module ?  Software forced events have the highest priority.

3. And finally, why doesn't this work (all the time) ?

Thanks.

  • Hi Gregory,

    I have looped in the relevant expert from the team, please expect a response back in the next day or so.

    Best Regards,

    Delaney

  • More information.

    I am not using the Deadband Control (DB) nor the PWM Chopper module (PC). Both of these modules are set at the default configurations (essentially bypassed with no effect).

    I would still like to know why the AQSCFRC does not work as expected. However, for now, I will configure the Trip Zone control to force the PWM outputs to a known state (all OFF). The Trip Zone module is near the end of the signal chain, and it's output will not be influenced by upstream modules.

  • Hi Gregory,

    Whether or not there is actually PWM occurring, I don't know

    Can you capture on an oscilloscope the moment when the PWMs are forced low by the AQCSFRC? Could you also see if a trip is occurring at the time of this AQCSFRC write? Are you using CBC trip or One shot?

    Are there any special conditions for using the continuous force register (AQSCFRC) ?

    The only configurations needed are configuring the AQSFRC.RLDCSF = 0x11 then writing to AQCSFRC.CSFB = 0x1, AQCSFRC.CSFA = 0x1 to set them low.

    Are there any trips occurring at this time that could override the AQ outputs? Could you disable the trip zone submodule, and test to see if the AQCSFRC is happening correct? With the removal of DB, and Trip Zone we can identify closer in the Action Qualifier submodule.

    Does the requested force condition in this register override any other requested output action from the PWM module ?  Software forced events have the highest priority

    Software forced events have the highest priority, however trips will override these if it were to occur.

    Best,

    Ryan Ma

  • Hi Ryan,

    Setting AQSFRC.RLDCSF = 0x11 did the trick for me. I was confusing PWM immediate load with software force immediate load. Another thing making the issue unpredictable for me was that I was setting a breakpoint right after the DisablePWM() function. This stopped the PWM timers so that the software force value(s) wouldn't be loaded until the next timer/counter event.

    Thank you for the help.

  • Hi Gregory,

    Glad it worked. I will go ahead and close this thread now.

    Best,

    Ryan Ma