• State TI Thinks Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 32 subscribers
  • Views 5503 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C123GH6PM: PWM Counter reset to apply new frequency settings instantly

Samy Ahmed
Prodigy 50 points
Part Number: TM4C123GH6PM

Hello Tiva community,

I am having a problem with my TM4C123GH6PM controller when I try to apply a new PWM period (i.e new frequency of the output of the PWM) instantly. The scenario is that we are running the PWM with an output frequency of 100 Hz and then we want to instantly change the output frequency to 100kHz without delay. The problem is that the PWM waits until the counter comes back to zero before applying the new frequency, which is too long for us when the counter has a frequency of 100Hz(that we need to have in the initial state). 

The solution we have tried is to reset the counter which should apply the new settings immediately, but unfortunately it did not work. We have the PWM configured as "PWMGenConfigure(PWM0_BASE, PWM_GEN_0, PWM_GEN_MODE_DOWN |PWM_GEN_MODE_DBG_RUN| PWM_GEN_MODE_NO_SYNC | PWM_GEN_MODE_GEN_NO_SYNC );" and below is how we have tried to change the frequency of the PWM:

PWMSyncTimeBase(PWM0_BASE, PWM_GEN_0_BIT); // resets the timer to zero

PWMGenPeriodSet(PWM0_BASE, PWM_GEN_0, cycle_time);
PWMPulseWidthSet(PWM0_BASE, PWM_OUT_0, 5);

PWMSyncUpdate(PWM0_BASE, PWM_GEN_0_BIT);  // updates the period change next time the timer hits zero

PWMSyncTimeBase(PWM0_BASE, PWM_GEN_0_BIT); // resets the timer to zero



When looking at an oscilloscope capturing when we send the command to change frequency and capturing the actual PWM output we still get a delay of 0.01 sec at most which is the time it takes for the counter to come back to zero at 100Hz, which is too long and we want to decrease the delay by a factor of 10 at least.

  • 0
    Guru 117855 points

    Let it be known that I've NOT tried this - yet it appears to be (logically) correct.     Might you try - then report?

    Should not you have employed function, "PWMOutputUpdateMode()" - with final parameter, "PWM_OUTPUT_MODE_NO_SYNC?"

    It is believed that your use of the "Sync Modes" - both Update & TimeBase - has caused your (unwanted) delay.

    PWMGenPeriodSet() and PWMPulseWidthSet() - just as you have listed - should "achieve your objective" with the (earlier occurring) addition of,  "PWMOutputUpdateMode()" parameterized as I've noted... 

    Avoid use of (either) Sync function - they've risen to "extreme suspect" rank in your issue...

  • 0 in reply to cb1_mobile
    Prodigy 50 points
    Hello, this did unfortunately not work. We have tried different combinations of the "sync modes" which according to the driverlib should take care of the problem, leaving us surprised when it did not.
  • 0 in reply to Samy Ahmed
    Guru 117855 points

    You provide NO Detail as to, "how you believe this - NOT to have worked!"       Minus your listing of your code - how can your implementation be confirmed?

    The description w/in the PDL "user guide" - I (just) now note - reveals: "This function is only available on Snowflake class devices."    And of course, "Snowflake class definition" is "well hidden" by this vendor.

    Let's "make the case for "Use of this Function."    TM4C-DRL-UG states the following for: "PWM_OUTPUT_MODE_NO_SYNC" parameterization:   "Enables/disables changes to take effect immediately."    And - that's "just what you seek - is that not true?

    Should the function (not) be available for TM4C123 - cannot you review the (provided) source code for the function - to see if (some) work-around may be devised?    (if you start that process - staff & I will do our best to "help you succeed."

  • 0 in reply to cb1_mobile
    Guru 117855 points

    I've got a meeting to attend - yet believe that you MUST quickly follow the NEW calls to:

    PWMGenPeriodSet() and PWMPulseWidthSet()      (these required for you to "update" the PWM Frequency & Duty Cycle)

    with a (new) call to:   PWMOutputState()    (just after the 2 calls - above)

    Prior to ALL of these function calls - you must have employed, "PWMOutputUpdateMode()" with the parameter I listed (earlier) for you...

    Kindly implement & advise.     (I see no "special register" (after a quick look) which would prevent this function from performing w/ "4C123."

  • 0 in reply to cb1_mobile
    TI__Guru*** 135355 points

    Hello Samy,

    There is a note in the TM4C which reads as follows: "Disabling the PWM by clearing the ENABLE bit does not clear the COUNT field of the PWMnCOUNT register. Before re-enabling the PWM (ENABLE = 0x1), the COUNT field should be cleared by resetting the PWM registers through the SRPWM register in the System Control Module."

    Based on this, I suspect that even the PWMSyncTimeBase cannot be used to force the counter to zero before some sort of count cycle (in this case, your only count cycle) is completed. It doesn't seem to take effect instantly and immediately clear the counter in a manner which will allow the new period to take over when used for a single PWM channel.

    Therefore, I used the following code to reset the PWM peripheral and re-configure it. This provided the desired instant count frequency change requested. Please see if this is sufficient for your application.

            SysCtlPeripheralReset(SYSCTL_PERIPH_PWM0);

        SysCtlPeripheralEnable(SYSCTL_PERIPH_PWM0);

        PWMGenConfigure(PWM0_BASE, PWM_GEN_0, PWM_GEN_MODE_DOWN|PWM_GEN_MODE_NO_SYNC);

        PWMGenPeriodSet(PWM0_BASE, PWM_GEN_0, new_period);
        PWMPulseWidthSet(PWM0_BASE, PWM_OUT_0, new_dutycycle);

        PWMOutputState(PWM0_BASE, PWM_OUT_0_BIT, true);

        PWMGenEnable(PWM0_BASE, PWM_GEN_0);

    (And yes cb1, I did try your method first with using PWMOutputUpdateMode - it did not have the desired effect either. I tried quite a few logical combinations with it as well to no avail unfortunately.)

  • 0 in reply to Ralph Jacobi
    Guru 117855 points

    @ Ralph,

    Thanks for that attempt - your kindness (for the mention) and effort (in trying - even "quite a few logical combinations") are both appreciated.

    I don't doubt that the "exhaustive, full, peripheral reset" you implemented will succeed.     However - that IS (somewhat) "brutal" -  leaving the device in receipt of the PWM signal, "at a loss" for the "combined execution duration" of ALL seven - added PWM functions!

    Harking back to the TM4C-DRL-UG - it is stated: "PWM_OUTPUT_MODE_NO_SYNC" parameterization:   "Enables/disables changes to take effect immediately."      This (claimed) immediacy is, "Just what our poster ordered" - and unless "erroneous and/or over-stated" - may (still) hold promise.     Upon my return to "home base" I'll "bot" the instruction combination process - and see if that "immediacy of PWM control" may be "teased out."     (I know we've achieved such "PWM immediacy" w/other's Cortex M4s - while the implementations are likely to differ - (some) facts/methods/findings may "overlap" - enabling exploitation!

    Appreciate your "jumping in" - are you able to check & determine if the pertinent "functional description" w/in the DRL-UG (which I've listed) has been "rejected/abandoned?"     Thanks your time/attention...

  • 0 in reply to cb1_mobile
    TI__Guru*** 135355 points
    Hello cb1,

    I don't disagree that method is somewhat brutal, perhaps I could have explained a bit more of why my conclusion provides a solution to what my interpretation of Samy's presented issue is.

    The immediately portion for the PWM_OUTPUT_MODE_NO_SYNC per my tests is immediately when a PWM counter reaches the count of 0 (in the case of this single instance of a DOWN count) which as far as I can tell was certainly the intended use case for the reasons you stated (not leaving devices in question as to why the PWM signal stopped mid-cycle), however, Samy made the following comment: "The problem is that the PWM waits until the counter comes back to zero before applying the new frequency, which is too long for us when the counter has a frequency of 100Hz(that we need to have in the initial state). "

    Under this premise, the only solution I uncovered to not wait for the PWM to finish counting to zero is the sledgehammer approach of using a full peripheral reset which halts the PWM in it's tracks and allows for a very quick frequency turn over.

    I also agree with the premise that indeed this could be leave the poor target device a bit out of sorts due to the suddenness, which depending on the device may not be ideal. But such 'immediate' response so as to not wait out the current period to finish would prompt that issue regardless - and again, this is what Samy requested. If this works for Samy's application and target device, who are we to question it - or is my mindset.
  • 0 in reply to Ralph Jacobi
    Guru 117855 points

    Well stated (again) Ralph - thank you.

    That said - does this not (continue) to "Fly in the face" of the "DRL-UG" - which (for years) has served as the "Key Tech (explanatory) Reference" - for so many (especially moi) here?

    I've presented (unchanged) the "intent" of that "PWMUpdateOutputMode()" function - when the "No Sync" parameter is employed.     Pity that thus far - neither you nor poster - have uncovered the (proper) sequence to achieve (the highly suggested) and so often desired, "IMMEDIATE PWM ALERATION!"

    One more key/critical point - is it not BEST to provide a "General Solution" which while "meeting poster needs" - is sufficiently expansive to cover the Broader needs of (the many) "follow-on thread readers" - who engage somewhat different operating details?     (clearly Yes - mais oui?)      Thus - our "acceptance" of a,  "less than sterling" PWM Update capability  - which (just barely) meets, "this poster's unique needs" - fails to REALLY (near universally) Satisfy!      That should be our real goal - is that not true?     (and proves best for your firm - too - compromised performance IS always uninspiring!)

    Are portions of the "DRL-UG" to be "held in dispute" (minus ANY factory notice) and if so - how & when - are we "ALL" to know?      

    These are not (entirely) "your" issues - but have remained "silent" - and the "bright (non-eclipsed sunlight" (presented here)  - proves the best,  "identifier/disinfectant" - does it not?

  • 0 in reply to cb1_mobile
    TI__Guru*** 135355 points
    Hello cb1,

    I'll post some logic captures of all methods in question when I get a chance to record them (today was not kind to me to get to this task) to see if we can come to a consensus agreement about what effect each option as regarding changing the PWM. Perhaps the captures will also allow you to provide me feedback should my coded interpretation of your suggestion not provide the expected result you anticipate! Either way, as soon as I get to providing these captures I think we'll be able to settle the debate on if DRL-UG is accurate as it should be for everyone's benefit. Stay tuned.
  • 0 in reply to Ralph Jacobi
    Guru 117855 points

    Greetings Ralph,

    Ralph Jacobi said:
    Stay tuned.

    I will - providing my "PLL Driven CAN Channel" does not, "Drift Off!"     (should not such inter-post "weaving" warrant - and receive - a "LIKE?")

    I too am, "behind the 8-ball" as I wanted to automate the "sequence of function calls" in the attempt to "tease out" the "reality" of the DRL-UG's Function - which (as written) Directly Satisfies Poster's Requirement.

    Again - solving "one poster's (limited) objective proves good" - solving the multitude's (more general) needs - proves great!    That stands as a "more challenging & proper (almost inspired) goal" - does it not?

  • 0 in reply to Ralph Jacobi
    Prodigy 110 points
    Hello,

    Samy, my colleague, has been on vacation. So on his behalf I apologize for the late answer.

    I just implemented your method Ralph, the peripheral reset, and it worked very well. It reduced our delay from 50 ms to around 0.2 ms.

    Thank you both very much for putting time and effort in to our problem. We sincerely appreciate it.

    Kind regards,
    Alan Goran
  • 0 in reply to Alan Goran
    Guru 117855 points
    May we thank you as well - Mr. Goran? (rare to be thanked)

    Is it "sure" that the "Loss of PWM Output" - even though brief - causes NO harmful effects? (such harm may not "arrive or be noted" immediately!)

    I still plan to automate the code sequence (and monitoring) - and employ the DRL's special PWM Function - which EXACTLY "Meets your Needs" (near instant PWM Freq change) - while avoiding the "Loss of PWM Output!"
  • 0 in reply to cb1_mobile
    Prodigy 110 points
    Hi

    It is not sure that it is not causing any harmful effects, because I have not done any extensive tests on it yet but everything looks alright, functionality wise.

    It will be a great feature to have the "instant PWM Freq change" function! As I mentioned before, we had a delay of 50 ms because of this, which is quite a lot of time.
  • 0 in reply to Alan Goran
    Guru 117855 points

    Alan Goran said:
    It will be a great feature to have the "instant PWM Freq change" function! As I mentioned before, we had a delay of 50 ms because of this, which is quite a lot of time.

    And - so too - is a delay of 0.2mS - especially when the DRL clearly states an, "Immediate PWM Update Function exists!"      (it cannot be "good" to transition the load from 100Hz - to "No Output" - and then to 100KHz - such is FAR from "textbook!")    [even the transition from 100Hz to 100KHz - done "immediately" - concerns ... ... preferred is a "series of incremental changes" - yet always w/"Gapless PWM" - not the brute force, compromised, "switch-off!"] 

    We're "not told" of the "load" or device which is, "PWM Controlled" - yet should it be a "normal" load - both the "intermediate buffer/boost circuitry" and (many) loads respond more favorably to more gradual changes...

    Your (and others'/our) "last/only" (best) hope - is that some combination of function sequence may "tease out" the immediate PWM update which IS promised by vendor's DRL!     (and "excused away...")