CCS/TM4C123GH6PZ: PWM When I give Duty Cycle 0, I get output like I'm giving 255

I "feel your language pain" - yet the issue is "NOT within the code!"

If you set the PWM Period to 255 - you cannot set the PWM Pulse Width, "HIGHER than around 249" - to be safe.
Likewise - you cannot set the PWM Pulse Width, "LOWER than around 5 or so" - again to be safe.

For example:

PWMGenPeriodSet(PWM1_BASE,PWM_GEN_0 , 0);  //   You report this as FAILING - yields 100% Duty Cycle!

Instead - try:

PWMGenPeriodSet(PWM1_BASE,PWM_GEN_0 , 5);  //    This should work - produces a (very small) Duty Cycle (< 2%)

This is NOT a fault w/in your code - it IS a (known) limitation w/in the ARM (and other) MCUs.

Possibly you can get a friend or teacher to assist your further read & understanding.     Wish you well...

Ali YOLCU said:

What do I need to do to make the PWM signal 0 ?

I have answered that - and supplied several methods to achieve just that - in my (first) responding post.

You may (also) choose to, "Switch the pin from "PWM (type & config) to GPIO" and then set it to logic "0."    Again - as past described (first post) - you must "test" for the desire to "set the Duty Cycle to ZERO" - and at that time - and that time only - reconfigure the pin from PWM to GPIO - and order it low!

Note that along w/(very) exhaustive written descriptions (several methods) I earlier provided sample code - which comes "so very close" to "0 Duty" PWM.

PWMGenPeriodSet(PWM1_BASE,PWM_GEN_0 , 5);   //  Provides less than 2% Duty when (your value) 255 provides the period.   You (may) attempt values of "1-4" - to lower the duty cycle even further!   (which "encroaches" upon the "safety factor" - may or may not work ... see the legal "boilerplate" (page bottom) specifically: "Providers of Content" (that's my work) beneficial to ALL "outsiders" here.)

cb1_mobile said:

As you seek to "avoid" hunch - why not start w/ARM - try & determine if this (known) PWM issue originated w/them

Manufacturers don't seem to be sharing PWM peripherals (although I may have missed a clue).

I don't know why this oversight keeps happening. It's not as if PWMs that cover the full range haven't been implemented before.

Robert

Robert Adsett said:

Manufacturers don't seem to be sharing PWM peripherals

Agreed!      And this is proves, "one more justification" for my firm's key clients/investors to  have pushed us to,  "Investigate the ARM MCU offerings of MANY (certainly NEVER just ONE) ARM Vendor."       And - we have noted that,  "Several ARM MCU Vendors - yet NOT ALL - appear to, "suffer"  this,  "PWM issue @ Duty Cycle Extremes!"     (thus the claim of  "hunch" was rather "uninformed" - or itself was, "poster's hunch!")

Now this, "Variation in Peripheral Implementation" extends beyond the PWM Module.     Many/most modern ARM MCUs contain a DAC, and highly capable, TFT Interface (absent here) , differences arise w/in Timers, ADCs, QEIs,  I2C (another  PWM-like, "difficult one") - the list grows.

And yes - years long past - our mighty Intel MCU (even Zilog) could dial up PWM Extremes - w/out (any) special care/handling.     In the defense of ARM -  vastly raised performance -  has necessarily raised the complexity level - of  many/most such MCU peripheral implementations.      And each "Vendor Implementation Team" has different design goals - different price points - so (some degree) of  peripheral variation is the "New Norm" - and IS to be  (grudgingly) expected!       (while being unwillingly - accepted...)

cb1_mobile said:

And yes - years long past - our mighty Intel MCU (even Zilog) could dial up PWM Extremes - w/out (any) special care/handling.

Also ST, Infineon and probably others. IIRC the TI PWM peripherals on their DSPs can also go the full range.

cb1_mobile said:

In the defense of ARM -  vastly raised performance -  has necessarily raised the complexity level

Well, no. That's a self inflicted wound really. Not everything needs to be more complex. CAN and UART come to mind, they're not more complex. Although TI's UART also appears to make some simple mistakes.

And really the PWM on the TM4C is not more complex than that on other devices that have got it right. At least as far as I can see.

I don't know whether I should be dismayed that they are repeating old specification mistakes or glad that they are repeating ones that we have know work arounds for. Maybe this peripheral design issue lies with the previous developer rather than TI? At least they had the excuse of unfamiliarity.

Robert

Robert Adsett said:

cb1_mobile

In the defense of ARM -  vastly raised performance -  has necessarily raised the complexity level

Well, no. That's a self inflicted wound really. Not everything needs to be more complex. CAN and UART come to mind, they're not more complex. Although TI's UART also appears to make some simple mistakes.

Should we (or our "pre-carnations") have existed in the 1800's - we'd each, "Reach for a pistol."     (Aaron Burr & Alexander Hamilton - for US history fans)

The ability of the ARM devices to:

• Synchronize Multiple PWM Channels
• Cease all PWM Outputs (immediately) - via a changed logic level - applied to a single MCU pin
• Accommodate so wide a range of PWM Frequencies
• produce coordinated PWM outputs - across 4 separate PWM Generators - impressed upon 8 MCU pins
• ability to, "Alter, Cease, or Add" the PWM (or multiple other) Functions - or key aspects of its operation - "on the fly"
• and maintain higher "accuracy & precision" - under varying temperature & voltage conditions (w/in spec)

works to support the (proper) claim of  "ARM's general superiority..."    (you could have wandered to the MSP device - is that not true?)

I must note your listing of one MCU vendor - claimed "not" to suffer from,  "PWM issue @ extremities" - which we must challenge.    (note: many MCUs are offered - our experience is unlikely to have (completely) overlapped.)

Should you "resist" - I've ordered a "dual set of matching pistols" - both fully loaded - and provided (only) minimal direction to the "border authorities" ... ("unload" the pistol - crossing to (your) side...)

Key word there may be needs. Although many or most of those features existed previous to ARM in other controls, notably in DSPs although the ST10 and C166 families from ST and Siemens/Infineon had fairly complex PWMs as well (also some reasonably complex timers). So none of this is specific to ARM processors

cb1_mobile said:

The ability of the ARM devices to:

• Synchronize Multiple PWM Channels
• Cease all PWM Outputs (immediately) - via a changed logic level - applied to a single MCU pin
• Accommodate so wide a range of PWM Frequencies
• produce coordinated PWM outputs - across 4 separate PWM Generators - impressed upon 8 MCU pins
• ability to, "Alter, Cease, or Add" the PWM (or multiple other) Functions - or key aspects of its operation - "on the fly"
• and maintain higher "accuracy & precision" - under varying temperature & voltage conditions (w/in spec)

Not specific to ARM devices. Other devices have this capability. I don't see why the added complexity of these features would make full PWM more difficult. Also to add to your list

• the ability to choose centre aligned or edge aligned PWM. I think some may have control over the phase shift between PWMs as well but it's been a while since I read the details.

cb1_mobile said:

I must note your listing of one MCU vendor - claimed "not" to suffer from,  "PWM issue @ extremities" - which we must challenge.

I'm just noting they have at least one device that did not suffer from that malady. Like having an interrupt occur on transmit buffer empty this is a widely solved problem, there's really no need to keep repeating it. Especially since it's a design/specification problem not an implementation one.

Is there a reason to believe it has a large cost in silicon? I don't think so but...

Now if your PWM was only aimed at controlling LEDs or, maybe, providing D/A then this oversight is fairly small. But for things like DC motor control* this capability is necessary and although there are workarounds the actual implementation of those can get a little tricky.

Robert

* AC motor control doesn't need to go full range and maybe that's the key. Maybe the PWM peripherals are designed with AC motor control in mind and the needs or other devices just aren't considered.

Do realize that you (may) be placing my "bi-weekly, stipend from ARM" - in (some) jeopardy...    C'est fini - et bien - mercî...