18F46K22 HPWM blips and errors

[comwarrior]

hi guys...
I've been trying to figure this out all weekend and I'm stumped...
I have a project that I'm doing for my sisters birthday. It uses all 5 hardware PWM on the 18F46K22.
However, i noticed the channels were 'bliping' and channels that were at 0% suddenly jumping to an on state and then back to off...

So, i set up some test hardware with two loop back fets to act as voltage regulators and LEDs to find the cause and it was still doing...

Still, no matter what i hang off the PWM's they blip randomly...
Even if i set them to a specific value and do not update the pwms', they still blip...
I have never seen this before and i have used the PWMs many time and not seen this. I tried all my other 46K22's and they do the same with the same firmware on.

So, I'll include the code from my last test setup... if someone would be so kind as to look over it to see if i have done something stupid...

Thanks



@ __config _CONFIG1H, _FOSC_INTIO67_1H & _PLLCFG_ON_1H & _PRICLKEN_ON_1H & _FCMEN_OFF_1H & _IESO_OFF_1H
@ __config _CONFIG2L, _PWRTEN_ON_2L & _BOREN_SBORDIS_2L & _BORV_220_2L
@ __config _CONFIG2H, _WDTEN_OFF_2H & _WDTPS_32768_2H & _CCP2MX_PORTC1_3H & _PBADEN_OFF_3H
@ __config _CONFIG3H, _CCP3MX_PORTE0_3H & _HFOFST_OFF_3H & _T3CMX_PORTC0_3H & _P2BMX_PORTC0_3H & _MCLRE_INTMCLR_3H
@ __config _CONFIG4L, _STVREN_ON_4L & _LVP_OFF_4L & _XINST_OFF_4L & _DEBUG_OFF_4L
@ __config _CONFIG5L, _CP0_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L & _CP3_OFF_5L & _CP1_OFF_5L & _CP2_OFF_5L & _CP3_OFF_5L
@ __config _CONFIG5H, _CPB_OFF_5H & _CPD_OFF_5H
@ __config _CONFIG6L, _WRT0_OFF_6L
@ __config _CONFIG6H, _WRTC_OFF_6H & _WRTB_OFF_6H & _WRTD_OFF_6H
@ __config _CONFIG7L, _EBTR0_OFF_7L & _EBTR1_OFF_7L & _EBTR2_OFF_7L & _EBTR3_OFF_7L
@ __config _CONFIG7H, _EBTRB_OFF_7H

Define OSC 64 ' Set clock speed

OSCCON.7 = 0
OSCCON.6 = 1
OSCCON.5 = 1
OSCCON.4 = 1
OSCCON.1 = 0
OSCCON.0 = 0
OSCTUNE.6 = 1 ; PLL

;INCLUDE "18F46K22 unlock.pbp"

ANSELA = %00000011
ANSELB = %00000000
ANSELC = %00000000
ANSELD = %00000000
ANSELE = %00000000

TRISB = 0
PORTB = 0
TRISC = %00000000
PORTC = 0
TRISD = %00000000
PORTD = 255
TRISE = 0
PORTE = 255
TRISA = %00000011

INCLUDE "DT_INTS-18.bas" ; Base Interrupt System
INCLUDE "ReEnterPBP-18.bas" ; Include if using PBP interrupts

ASM
INT_LIST macro ; IntSource, Label, Type, ResetFlag?
INT_Handler AD_INT, _ADC_HANDLER, PBP, yes
; INT_Handler HLVD_INT, _HLVD, PBP, yes
endm
INT_CREATE ; Creates the interrupt processor
ENDASM

VREFCON0 = %10100000

ADC0 VAR WORD
REDLEDPWM VAR BYTE
GREENLEDPWM VAR BYTE
BLUELEDPWM VAR BYTE
ADCCHAN VAR BIT
LOWVOLTAGE VAR BIT

ALOOP VAR WORD
BLOOP VAR WORD
CLOOP VAR WORD
DLOOP VAR WORD
TEMPBYTE VAR BYTE

PAUSETIME VAR WORD

CLEAR

VREG1TGT CON 535
VREG2TGT CON 815

ADCCHAN = 0
ADCON2 = %10111111
ADCON1 = %00001000
ADCON0 = %00000011
;HLVDCON = %00110111

REDVREGPWM VAR BYTE
GBWVREGPWM VAR BYTE

@ INT_ENABLE AD_INT
;@ INT_ENABLE HLVD_INT

REDVREGPWM = 255
GBWVREGPWM = 255
REDLEDPWM = 0
GREENLEDPWM = 0
BLUELEDPWM = 0
GOSUB UPDATELEDPWM
GOSUB UPDATEVREGPWM

PAUSE 1000

MAIN:

;We do something here to make the LED's produce pretty colors, ramp them up, down, flash them... and then "GOSUB UPDATELEDPWM" to update the PWM's

;REDLEDPWM = 0
;GREENLEDPWM = 0
;BLUELEDPWM = 0
;PAUSE 1000
;GOSUB UPDATELEDPWM
;GOTO MAIN
;REDLEDPWM = 128
;GREENLEDPWM = 255
;BLUELEDPWM = 128
;GOSUB UPDATELEDPWM
;Pause 1000
;REDLEDPWM = 128
;GREENLEDPWM = 128
;BLUELEDPWM = 255
;GOSUB UPDATELEDPWM
;Pause 1000
;REDLEDPWM = 255
;GREENLEDPWM = 128
;BLUELEDPWM = 128
;GOSUB UPDATELEDPWM
;Pause 1000
GOTO MAIN

ADC_HANDLER:
ADC0.LOWBYTE = ADRESL
ADC0.HIGHBYTE = ADRESH
IF ADCCHAN = 0 then
IF ADC0 < VREG1TGT then
IF REDVREGPWM > 0 then REDVREGPWM=REDVREGPWM - 1
ELSE
IF REDVREGPWM < 255 then REDVREGPWM=REDVREGPWM + 1
ENDIF
GOSUB UPDATEVREGPWM
ADCCHAN = 1
ADCON0 = %00000111
ELSE
IF ADC0 < VREG2TGT then
IF GBWVREGpwm > 0 then GBWVREGpwm = GBWVREGpwm - 1
ELSE
IF GBWVREGpwm < 255 then GBWVREGpwm = GBWVREGpwm + 1
ENDIF
GOSUB UPDATEVREGPWM
ADCCHAN = 0
ADCON0 = %0000011
ENDIF
@ INT_RETURN

UPDATEVREGPWM:
HPWM 1,REDVREGPWM,3000
HPWM 2,GBWVREGpwm,3000
RETURN

UPDATELEDPWM:
TEMPBYTE = 255 - REDLEDPWM
HPWM 3,TEMPBYTE,3000
TEMPBYTE = 255 - GREENLEDPWM
HPWM 4,TEMPBYTE,3000
TEMPBYTE = 255 - BLUELEDPWM
HPWM 5,TEMPBYTE,3000
RETURN


Be aware, the PWM outputs are in this case inverted due to direct drive of P channel fets. Tried with and without fets, transistors etc etc...
Also, actual PWM frequency is 12.9KHz due to the 4X PLL bug still present in PBP 2.60C

All help greatly appreciated...

[Dave]

I see something I don't like. You are making a call to a subroutine that is outside of the interrupt routine you are in. BAD coding practice...

[HenrikOlsson]

Hi Dave,
Would you care to elaborate a bit on WHY exactly that is such BAD practice (as long as you RETURN of course)?
Yes, it does put another return adress on the stack but really, that's usually not a problem - certainly not with 18F parts where you can nest 27 levels deep.

My guess is that the "blips" are comming from the frequent updates of the dutycycle using the HPWM command. It's my understandning that it (the HPWM command) reconfigures the CCP module completely every time it executes even though it's only the dutycycle that changes.

Another thoguht: I don't know about the "PLL-bug" mentioned but perhaps the HPWM command calculates the dutycycle value based on the wrong frequency so the registers overflows or something?

Bottom line is, try setting the CCP modules up manually and see if that helps, there should be plenty of examples around the forum.

/Henrik.

[Demon]

I always thought it was best to keep the coding within an interrupt to a minimum. I set flags and then check for them in my main logic.

If code absolutely has to execute within the interrupt, I'd place it in-line. I would think calling an other subroutine chews cycles needlessly.

Robert

[comwarrior]

Henrik,
I agree with you that it must be the HPWM command that is causing the blips since the 46K22 has a buffered PWM.
However, as you can see from the source code, i do most things by setting the register directly like the ADC scanning. However, i have not yet been able to get the PWMs to work by setting them manually.
The PLL bug is because certain elements of PBP do not account for the 4 times increase of the clock speed due to enabling of the on-board PLL. It's those elements that ignore "Define OSC" and try to determine clock speed on their own.

Demon and Dave,
I agree the code is not optimal, it's the resultant mess of trying to debug the problem and sticking stuff in subroutines so that i can call it anywhere and not have to worry about it coming back correctly.


I'll go take a look for manual setting of the PWM and see if that sorts it...

Thanks guys.