PWM Duty Cycle Problem

[MotoDan]

Hi guys,

I'm using a PIC16F18324 and am having trouble understanding why my PWM duty cycles are not working out the way they should.

My compiler is the latest PCM 5.080.

I'm running the device from the internal clock at 32 MHz and am setting up Timer2 for a PWM freq of 10 kHz (PR2 = 200) which works as it should.

The problem is when I use a duty cycle value of 100 (50% duty or 1/2 of PR2), I'm getting a duty cycle of 12.5% (1/4th of 50%). I have to use a value of 400 in order to get a 50% duty. The list file shows this to be the case, but I can't figure out why I get 1/4th the expected duty cycle. I've read where forcing the duty cycle to be a 16-bit value (100L vs 100) should cause the compiler to use a 10-bit value vs an 8-bit value for the duty cycle, but this doesn't seem to make any difference. The 8-bit vs 10-bit value for the duty cycle could explain a 4x difference in duty cycle that I'm seeing.

I've used PWM on PIC16's and PIC18's many times before, but have never experienced this problem with the duty cycle.

Thanks in advance!

[PCM programmer]

Read the last few posts of this thread:
http://www.ccsinfo.com/forum/viewtopic.php?t=57298

When Ttelmah says "surprised ?", yes I was surprised. CCS has made an
un-announced change that we discovered in that thread.

[MotoDan]

Thanks PCM.

Not sure if the compiler has changed lately for the way the duty cycle is handled for this PIC. I just tried an older v5.061 and the results were the same. It looks to me like the PWMxDCH:PWMxDCL register are not being filled properly.

Think I'll see if CCS can shed some light on this.

[jdean]

MotoDan: I believe the issue is that set-pwm5_duty is an overloaded function supporting either an 8-bit or 16-bit argument. Looking at the documentation, the 16-bit variant produces a duty-cycle that is 1/4 of the 8-bit version given the same argument.

My best guess is that the breakage is due to a recent change in overloaded function selection which I've seen referenced in another thread. If you instead call the function with an int8 argument, you should get the correct result.

Cheers!

[MotoDan]

Thanks jean, but I get nothing when I use an 8-bit int set to 100;

Here's what I finally concluded: The compiler seems to be doing what it's supposed to. The issue is that Microchip split the 10-bit PWM duty cycle register up so that the lower 2 bits are in the LSB and the upper 8 bits are in the MSB. This is why setting the duty cycle via set_pwm5_duty() routine results in a duty cycle that is 1/4 (shifted left 2 bits) of the traditional value seen on other PICs.

From the datasheet:

PWM5DCL:

PWM5DC<1:0> lower 2 bits
PWM5DC<9:2> upper 8 bits

So if you are wanting to set the duty cycle where the value is a direct percentage of the Timer2 (PR2) value then you must use the PWM5DCH register, but you will be limited to 8-bit resolution.

Thanks for everyone's input!

[jdean]

Happy to see you have it sorted, sad to see that you had to resort to a direct register write to pull it off.

This part is odd:

[MotoDan]

You can still use the setup_pwm5_duty() routine. You just have to be aware that the duty cycle period value is 4x what you might think.

[jdean]

Yes and no.

You can use it with a literal argument and get the 16-bit behavior from the documentation. eg:
setup_pwm5_duty(100)

However, if you need to set your duty cycle from a variable instead, then you'll have to be sure to use a 16-bit variable, as the 8-bit version is either clearing PWMxDCH, or, more likely, stuffing it with garbage.

That is of course, assuming the 16-bit variable version isn't also showing a similar fault.

[fernandokestering]

#use pwm(output=pin_c2, timer=2, frequency=50kHz, duty=50)

[Ttelmah]

I think explicit forcing would work in all cases.

So:
(int8)100
as the value used. Should give the 4* value, while:
(int16)100
should give the smaller value.

What seems to have happened is that a constant is by default being treated as int16, whatever it's size. This wasn't the case in the past, but it may be a long way back in time when this was actually changed...

[Ttelmah]

This is actually stranger yet.

If you look at the assembler, it is dividing whatever value it is given, by four before passing it into the function.

If you use pwm1, instead of pwm5, it behaves as normally expected, and does accept an 8 bit or 16bit value OK. If is the pwm5/6, only, that giving this issue.
It is doing the same if you pass it a variable:

[MotoDan]

This device only has PWM5 and PWM6. The compiler will reject the setup_pwm1() statement, but will allow setup_pwm1_duty(). Not sure why Microchip doesn't use PWM1 and PWM2 instead.

I have submitted a support request from CCS on this. Will report back any findings.

[Ttelmah]

No, it has two CCP's.
You can set these as PWM's and they then work for the duty instructions.
The setup syntax is different though. setup_ccp1(CCP_PWM). The setup_pwm function only works for explicit PWM's as opposed to a CCP setup as a PWM.

[Ttelmah]

Thinking about it, I think CCS have attempted to make the explicit PWM 'resemble' the CCP PWM's, so emulating the *4 behaviour. Unfortunately the cast they use to do this (which should switch between using /4 and /1 depending on whether you use an int8 or an int16), is not working correctly. Hence the effect being seen here.