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.
I am using a GPTM in PWM mode to control a stepper motor driver. The width of each pulse should be the same, but frequency of the pulse train should ramp up and then down, to create a trapezoidal velocity profile for the motor. The new timer period is calculated and applied to the timer in an "acceleration" interrupt that is triggered by the rising edge of the timer's CCP signal. I have tested this code a fair amount and found that it works perfectly, unless the starting frequency of the pulse train is too low.
This picture shows the expected operation. Channel 1 (Yellow) is the pulse train generated by the GPTM. Channel 2 (blue) is a GPIO pin that is set high upon entry to the acceleration ISR and cleared upon exit from the ISR. The acceleration interrupt is (intentionally) disabled for the 3 pulses in the middle, because the middle portion of the move is expected to be at a constant velocity.
Here is a close-up of a pulse with acceleration enabled:
When the starting frequency of the pulsetrain is below a certain threshold, the following glitch happens:
Here is a close-up of the glitch:
Here is the initial configuration of the GPTM:
MAP_TimerConfigure(MOTOR_A_PWM_TIMER_BASE, TIMER_CFG_SPLIT_PAIR | TIMER_CFG_A_PWM);
MAP_TimerControlLevel(MOTOR_A_PWM_TIMER_BASE, TIMER_A, false);
MAP_TimerControlEvent(MOTOR_A_PWM_TIMER_BASE, TIMER_A, TIMER_EVENT_POS_EDGE);
TIMER_UP_LOAD_TIMEOUT | TIMER_UP_MATCH_TIMEOUT);
TimerIntRegister(MOTOR_A_PWM_TIMER_BASE, TIMER_A, motor_A_accel_ISR);
Here is the function that sets a new frequency for the GPTM:
static void pwm_period_set(uint32_t timer_base, tcount_t period)
tcount_t match_val = period - STEP_PULSE_COUNTS;
// Set 'Load' value
HWREG(timer_base + TIMER_O_TAILR) = (uint16_t)(period & 0xFFFF);
HWREG(timer_base + TIMER_O_TAPR) = (uint8_t)((period >> 16) & 0xFF);
// Set 'Match' value
HWREG(timer_base + TIMER_O_TAMATCHR) = (uint16_t)(match_val & 0xFFFF);
HWREG(timer_base + TIMER_O_TAPMR) = (uint8_t)((match_val >> 16) & 0xFF);
I wrote some code to capture the 'period', 'match_val', and TAR register at the end of each invocation of the function 'pwm_period_set'. Examining the data, I found that the glitch only occurs if TAR is greater than 'period' (by more than a few counts) at the end of the 'pwm_period_set' function. Here are the two data points that show this threshold frequency:
Issue appears here:period = 29897match = 29097TAR = 29992
Issue doesn't appear here:period = 28848match = 28048TAR = 28852
Note that this issue never occurs when the GPTM frequency is decreasing (deceleration), only when the frequency is increasing. From this I conclude that (in PWM mode) it is not safe to set a new GPTM period that is less than the old GPTM period IF the current TAR value is greater than the old GPTM period. What exactly is going on?
NOTE: I am using a TM4C123GH6PM, silicon rev. 7, with TivaWare 22.214.171.124.
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Amit Ashara:
The TAR is more than the next TAILR, not the current TAILR. I am increasing the PWM frequency, shortly after the start of each PWM period, using the 'update on timeout event' mode. The Period and Match values that I reported are the values for the next PWM period, which I configure during 'pwm_period_set'. The TAR value that I reported is the only value related to the current PWM period.
The issue is that the new Period and Match values should not take effect until the 'timeout' event, since I am using the 'update on timeout event' mode. But this expected behavior happens only if TAR is less than the new TAILR value when I write this new value to TAILR. Otherwise, I see this glitch.
In reply to Oliver Douglas69:
According to the data sheet, "The timer is capable of generating interrupts based on three types of events: rising edge, falling edge, or both." (pg 716)
I assume in this case that 'Match TimeOut' means a falling edge, since my PWM signal is configured to go high when the timer reloads, and low when the match event occurs. Choosing rising or falling edge interrupts makes no difference in whether or not the bug appears. Moreover, I have ensured that TAILR is always more than TAMATCH. If you are in doubt of this, please look at my 'set_pwm_period' function.
The glitch shows up if TAR is greater than the new TAILR value when I write the new TAILR value. It seems to me that this is either a hardware bug or a very unfortunate omission from the design of the timer hardware. I do not see why the current value of TAR should have an impact on updating TAILR, if the TAILD bit in TAMR is set. I should be able to schedule an update on TAILR to occur the next time TAR hits zero. Doing this should not affect anything in the current PWM period, regardless of when the write to TAILR occurs (except perhaps if the write occurs in the few clock cycles just before TAR hits zero).
Your response suggests that the Timeout event, and therefore the TAILD bit in TAMR page, are totally irrelevant to the PWM mode. I find this quite surprising. If this is true, then
Can you please clarify for me if this is correct?
I have attached a simple CCS project that demonstrates the bug. Please connect pin PB.6 of an EK-TM4C123GXL launchpad to an oscilloscope to see the PWM glitch that I described. The test program runs two trials, each of which generates a pulse train for about 3 milliseconds. There is a gap of roughly 4 milliseconds in between the two trials. The first trial should demonstrate the intended operation (no glitch), while the second trial should show a glitch similar to what I described previously.
Thank you very much for looking into this issue.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.