Over-length pulse sometimes generated when PWM period changed

I've checked that when the update-timings code is run, the variables are set correctly: pwm_gen_id is 0x40 and pwm_gen_bit is 1, which I think is correct as I am using PWM output 0.

The write to the GENA register is only needed on the first call, to enable the pulse generation, so I also tried preceding it by

if (HWREG(PWM0_BASE + pwm_gen_id + PWM_O_X_GENA) != 0x8c)

to see if the problem is caused by that write: but it made no apparent difference.

OK, here is an standalone example project.  It generates a PWM output on PF0, which should switch cleanly between 50us and 25us period.

This seems to only show the incorrect waveform when switching from 25us to 50us period and not the other way.  I set my scope to trigger on high pulses of over 26us to catch the errors.

The same incorrect waveform output happens if CMPA is written before LOAD.

pwm_issue.zip

I have realised that both types of incorrect waveform could be explained if the CMPA register is sometimes getting updated on the cycle after LOAD.  But if I've correctly enabled and used 'global synchronisation' mode, they should be getting updated at the same time.

Michael

Working at another (large) semi firm - we were advised "not" to confine our test/verifies to any, "special treatment and/or handled pins." PF0 is "such a pin" upon 4C123 - I don't know about user's "4C129." It may prove useful to test to see if this issue "generalizes" to other pins - and other ports. (ideally "standard" pins)

On a related note - firm/I have never/ever been able to note a "solid" difference between "Global & Local" Sync.   Amit's made the effort to past explain - yet our tests cannot detect any difference.   A tested/proven code example (via the API) would prove useful - I believe poster's report - and my firm's notice - (may) have identified the "tip" of a "mal-performing, PWM iceberg..."

Hi matten,

May have seen similar behavior with the LM3S when triggering ADC in down count using PWM_TR_CNT_BD -- though not exactly the same issue. Sometimes the generator outputs A/B do not change state ignoring the NEW load value if greater comparator match values are asserting The pulse width is extended as a result (given below). Even worse when dead band enabled, A out is inverted and becomes B out by the delay time and the ignored greater matching count values never get loaded.

23.3.3 PWM Comparators

Each PWM generator has two comparators that monitor the value of the counter; when either comparator matches the counter, they output a single-clock-cycle-width High pulse, labeled "cmpA" and "cmpB" in the figures in this chapter. When in Count-Up/Down mode, these comparators match both when counting up and when counting down, and thus are qualified by the counter direction signal. These qualified pulses are used in the PWM generation process. If either comparator match value is greater than the counter load value, then that comparator never outputs a High pulse.

BP101 said:

If either comparator match value is greater than the counter load value, then that comparator never outputs a High pulse.

Your sentence in highlight is difficult to relate to this thread.  

Poster reports, "Over Length" pulse - not a, "Loss of High Pulse" as you highlight!

Hello Amit,

I'm afraid it's not very clear to me what you are suggesting as a workaround.

Amit Ashara said:

the suggested workaround would be to use the interrupt status to write the value of the new load and comparator, clear the raw status bit for Count of 0 and then write the Global Sync bit.

I can see that the count zero interrupt flag (PWMnISC bit 0) can be set up to give a "PWM counter has passed through zero" indication without actually generating an interrupt, by setting bit 0 in PWMnINTEN; writing PWMnISC with bit 0 set will clear the flag and it will be set again when the counter passes through zero.
Am I correct to say that your suggested workaround is to write the new values to PWMnLOAD and PWMnCMPx, then wait for the PWM counter to pass through zero (using the method above) before writing to PWMSYNC to trigger the register update?

Has anyone at TI investigated the scope of this issue? I'm wondering whether the problem only applies to the LOAD register, or could it also occur on other registers configured for "Globally Synchronized" update, such as the CMPA/B, GENA/B and PWMENABLE registers?

Thanks,

Michael

Hi Amit,

While on topic of errata can you perhaps verify PWM0n dead band generator (pwmB) seemingly produces PWMnDBFALL output when disabled. Chuck was assisting us on this issue and refused to go further without example SW, (pwm) needs a rewrite to run on TM4C1294 launch pad.

Hi Chuck

Sorry Chuck not sure how these posts were cross treaded however not by me!

Seems you posted in this thread but it also showed in the original thread I replied to.

As stated I was not attempting to as your stating to hijack this thread. Quite obviously I was unaware nor have ever had a moderator interject his view in Response to a question asked to another poster. That seemingly violates confidentiality rules and if anyone was hijacking a thread perhaps it was you and not I. Obviously I responded to your question believing it was posted in the thread it was thought to be intended for. From my view point that was a devious action on your part and I was made the sacrificial lamb.

I've tried the suggested workaround and it makes a big difference: the over-length pulse now happens much more frequently (possibly every time), and on both increasing and decreasing PWM period!

I've attached the modified project, but all I have changed is to add, in the initialisation stage:

HWREG(PWM0_BASE + PWM_GEN_0 + PWM_O_X_INTEN) = PWM_X_INTEN_INTCNTZERO;

and before each write to PWMCTL:

HWREG(PWM0_BASE + PWM_GEN_0 + PWM_O_X_ISC) = PWM_X_ISC_INTCNTZERO;
while (!(HWREG(PWM0_BASE + PWM_GEN_0 + PWM_O_X_ISC) & PWM_X_ISC_INTCNTZERO)) { }

Which is what I understood the suggested workaround to be.

Maybe I have misunderstood or mis-implemented the workaround - could you just post the code you used to verify the workaround at TI?

Michael

pwm_issue_wa1.zip

Again If offering an alternate solution responding a posters issue constitutes hijacking then many in this forum are equally guilty of that. Including anyone that attempts to redirect a posters issue from achieving a rapid solution by giving unwarranted instruction to alter course based on a premise their logic is more sound than yours.