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.

CCS/TM4C123AE6PM: GPIO used for PWM signal

Part Number: TM4C123AE6PM

Tool/software: Code Composer Studio

Hello everyone, 

I have a bit general question before I start to modify my code with this new method for PWM signal generation. I have on two pins requirement for PWM signal which should be modifiable by frequency and duty cycle with frequency in the range of 1-200 Hz. Since I have problems with generating that signal with wide timer, and do not have PWM module on connected pins I plan to generate PWM signal using pin as GPIO and some timers for counting when the GPIO should be on and off. Can it be achieved that way? 

Thank you!

  • Djedjica said:
    Since I have problems with generating that signal with wide timer

    What problems?      "Teasing" never proves as helpful as, "Real presentation/description" of your results!

    Breaking from the Timer - which clearly is designed to support, "EXACTLY what you seek" - and employing (instead) a "high effort - REINVENTION OF THE WHEEL" makes little sense!     (IMO)

    If you fully/properly report your "problems" (beyond "Does NOT Work!") surely the brigade of forum helpers (even those "official") should arrive to comment & assist...

  • Yes,  I'm sorry I am anxious to finish this work already and therefore I leave post with little useful information. I searched over the forum already for my problem with wide timer and cannot find solution which I could build in for my requirements. So, the frequency of PWM signal is increased with potty (1Hz - 200 Hz), and when increasing frequency every now and then I get a full load, signal stays in 1 for some period of time. Since PWM is connected to the motor, even without monitoring oscilloscope signal, the user can hear when the motor spins at full speed even if PWM is at 5%. 

    Here is code snippet for timer setup: 

    	SysCtlPeripheralEnable(SYSCTL_PERIPH_WTIMER5);
    	GPIOPinConfigure(GPIO_PD6_WT5CCP0);
    	GPIOPinTypeTimer(GPIO_PORTD_BASE, GPIO_PIN_6);
    	period = SysCtlClockGet()/200;	//200Hz default 
    	dutyCyclePWM2 = (unsigned long)(period-1)*(1-(5.0/100.0));	//5% default
    	TimerConfigure(WTIMER5_BASE, (TIMER_CFG_SPLIT_PAIR|TIMER_CFG_A_PWM));
    	TimerUpdateMode(WTIMER5_BASE, TIMER_A, TIMER_UP_LOAD_TIMEOUT | TIMER_UP_MATCH_TIMEOUT);
    	TimerLoadSet(WTIMER5_BASE, TIMER_A, period-1);
    	TimerMatchSet(WTIMER5_BASE, TIMER_A, dutyCyclePWM2);
    	TimerEnable(WTIMER5_BASE, TIMER_A);

    And when necessary to change frequency or duty cycle of the signal,  I use TI functions to change load and match of the timer (TimerLoadSet() and TimerMatchSet()).

    Sorry I can't post my imgs I wait for electronics to come from production, that is next week. But I found this post which exactly describes my problem

    https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/530418?tisearch=e2e-sitesearch&keymatch=synchronous%20update%20of%20timer%20match%20and%20load%20values%20pwm#pi239031350=2

    , and the only solution provided is to move to PWM module. That does not fit for me since my outputs are on pins with wide timer and no PWM module function. I set my all hopes to this wide timer. 

    That is why now I am searching for an alternative way to generate PWM signals, since PWM module is no option for me now (), and I must give up on the wide timer since this glitch is unacceptable on our product. 

  • Djedjica,
    There exists no "defect" on the timer module for using a simple PWM signal. If/when you configure it properly, it will work. So you don't need to consider a "different approach" such as controlling a GPIO by bit-banging, as you initially suggested.
    There is just something wrong with your parameters. Debug them properly until you find out what is wrong with your math.
    For one thing, I find it suspicious how you use the following line:
    (unsigned long)(period-1)*(1-(5.0/100.0))
    The case just converts to long the (period-1), but not the whole result - might this be your problem? Breakpoint with some conditional and check the value you are passing to the timer configuration.
    Let us know! Good luck.
    Bruno
  • Thank you for your suggestion Mr. Saraiva. I have no problem with this signal when changing duty cycle from 1-100% or when signal is still. Only when changing frequency, so it seems to me that this changing load value on timer, while running, is the problem. And it is exactly as described in post from the link.
  • I see...

    So let me "think about it" here:

    - the duty cycle is a fixed value in which the output is inverted...
    - let's say your timer is counting to 8,000,000 (for the sake of a 10Hz signal on a TM4C123 @80MHz)
    - And that you had the duty cycle set for 75%, meaning the PWMmatch value would be 6,000,000.

    First, say you are decreasing your frequency from 10Hz to 6Hz, you would be increasing the load from 8,000,000 to 13,333,333... The match value being the same, you could have a brief moment in which the duty cycle would be less (45%), but probably there would be no glitch... Can you confirm that?

    Now, the other way: you are increasing your desired frequency from 10Hz to 20Hz, the load would be changing from 8,000,000 to 4,000,000. With the match value staying the same, at 6M, we have a match higher than the actual load... Could this be your problem? If so, then I guess than all it takes is to verify if this "explosion" situation is prone to happen, and correct the duty value before applying the new frequency...

    Anyway, just an attempt for an organized thought here, while I rest from other "fine timing problems of my own"!

    Bruno
  • Have "Liked" your effort & logic in the above post - good that. Yet - "Not so much" in your (likely) "speed-read" of the earlier post - in which poster reported his to be an, "Admitted MCU Timer Issue" - unlikely to be "poster caused."

    All pertinent facts must be examined - and if relevant/helpful - admitted into evidence.      (rush often prevents this - might this be a tendency - which (now) being identified - may be corrected?)

  • Djedjica said:
    I have no problem with this signal when changing duty cycle from 1-100% or when signal is still. Only when changing frequency

    Only when increasing frequency perhaps?

    But that raises another question. If this is controlling a motor why are you changing frequency? For that matter why so low a frequency?

    Robert

  • Yes, only when increasing frequency, I'm sorry I thought I mentioned that, now I see I only wrote when changing. And idea was also that problem occures if match stays higher than period value while in transition from one frequency to another. Maybe I put wrong bits set for Timer update mode?
  • OK, then that's probably your issue (you still haven't addressed the other questions though).

    Consider what happens when you reduce the period to increase the frequency.  

    Say your period is initially 1000 and you reduce it to 500.

    • Now what happens when you change the period if
      1. Your timer counter is at 300?
      2. Your timer counter is at 600?

    Robert

  • If indeed this is a "known issue" - and occurs ONLY (as you note) when changing frequency - is it possible to employ a 2nd Timer - which comes "into play" ONLY when you seek to, "Change Frequency?"

    You should be able to impose a logic gate between the (now) TWO Timer Outputs - such that the output (felt at your motor) comes from either of those 2 Timers.     (but only from one at a time.) 

    Implementation would see you:

    • "Load the 2nd Timer w/the "new frequency"   (this 2nd Timer would be disabled/idled prior to this load of your newly desired frequency)
    • then "Disable" the running timer (which you report as "preparing to glitch")
    • then "Enable" the 2nd Timer - which contains the NEW .... yet importantly not any "CHANGED" Frequency (thus should be glitch-free)
    • in a similar "round-robin" fashion - you would switch between Enabled Timers - changing  "Load values on the currently idle Timer" - but NOT (while running!)

    Indeed this does involve "monkey motion" - and use of a 2nd Timer - but w/5 minutes "thought investment" - seems (almost) inspired & if what you report is correct - this method should succeed!

    May I note that to "Prevent" such "unfortunate discoveries" - so late in the design process - should you not have "TEST/VERIFIED" ALL of your key assumptions (via an Eval Board) - and only then committed to MCU Selection and pcb design?        (this is the method we advise our clients - and after the obligatory "Client Eye-Roll" - those who follow that guidance, Raise their Odds!     (eye-rollers - in contrast - DESERVE their FATE - which I "delight" in recalling when we are "called in" for Rescue Opeations...)

  • Yes, that was idea, that maybe I did not set correct update mode. As you can see in code sinppet I when setting update mode I set TIMER_UP_LOAD_TIMEOUT and TIMER_UP_MATCH_TIMEOUT bits. If I understand right, it makes timer to update new values for period and match when timer counts down to zero, not somewhere in between. Or i missed something?
  • Robert - your presentation IS insightful - its logic undeniable - but "all may not be right" w/in the Timer. And - as poster reports - and I (almost) can recall - vendor's Amit confirmed such a weakness.

    If you will - might you vector up 2-3 posts - and find/comment upon my direction to employ a 2nd Timer.     (either Timer may thus be gated on thru to the motor...)

    I've another "swag" - might forcing the Timer to its LOWEST (resulting duty cycle) and then "quickly, almost immediately" setting it to the desired value - camouflage and/or avoid the issue? (note that the "near zero" duty cycle would be very brief - "imperceptible to the motor" - don't you agree?

  • Yes, I will try to test that as soon as my electronics arrive, as I said new revision comes form production to my desk next week. But what about setting Timer update mode bits to update new values of period and match on timer timeout? I thought that this addresses those situations.
    TimerUpdateMode(WTIMER5_BASE, TIMER_A, TIMER_UP_LOAD_TIMEOUT | TIMER_UP_MATCH_TIMEOUT);
  • Djedjica said:
    Yes, I will try to test that as soon as my electronics arrive,

    No test needed. This is a logic problem. Sit down at your desk with pen and paper and work it out.

    Djedjica said:
    what about setting Timer update mode bits to update new values of period and match on timer timeout?

    What about it? It doesn't address the current timer count.

    Robert

  • Another thought dawns - (actually TWO):

    • Why wait - that's Krazy - find an Eval or LPad - they are (likely) to deal w/this issue identically
    • Would it not be useful for you to "PLAY" with first ONE - then BOTH of those Timer Settings - but... ... ... Alter (change them) then by the SMALLEST AMOUNT which causes the issue.      That should "pinpoint" your issue - and when reported here - more brain cells may be burned in your behalf...

    The issue is to be able to RELIABLY BREAK the Timer - upon COMMAND!     Once that's known/done - the odds of (some) fix MULTIPLY!

  • cb1_mobile said:
    I've another "swag" - might forcing the Timer to its LOWEST (resulting duty cycle) and then "quickly, almost immediately" setting it to the desired value - camouflage and/or avoid the issue? (note that the "near zero" duty cycle would be very brief - "imperceptible to the motor" - don't you agree?

    Well I don't think changing the frequency is likely to be meaningful. Well, that's not entirely true but no case has been presented for it.

    Forcing the timer to the lowest duty cycle might make the problem worse. Forcing the timer value would. Generally the solution is to be cautious of timing, maybe with a two step frequency update.

    Robert

  • Ok, sorry if I understood something wrong but in software I do not address current value of timer count. Only upon detection that frequency needs to be changed I go to procedure to calculate new values (period and match) and set them in timer registers. But it all happens in main program loop. Is that what You were asking me?
    And reqirements for system I get from another department, and for some idea they want this low freq PWM which also has modifiable freq.
  • Djedjica said:
    Only upon detection that frequency needs to be changed I go to procedure to calculate new values (period and match) and set them in timer registers. But it all happens in main program loop. Is that what You were asking me?

    No I'm asking you to consider these questions I posed earlier

    Robert said:
    Say your period is initially 1000 and you reduce it to 500.
    • Now what happens when you change the period if
      1. Your timer counter is at 300?
      2. Your timer counter is at 600?

Robert