100 views and not one comment or suggestion... surely someone has some idea as to what's happening ????
100 views and not one comment or suggestion... surely someone has some idea as to what's happening ????
Hi,
I think you need to try and recreate the issue with as little code as possible. Start from scratch, can you get a steady duty cycle out of both modules without the aditional on/off toggling or does the toggling happen as soon as you try to get PWM out on PortC.2?
/Henrik.
This is actually a somewhat tricky problem. Without spending a couple hours going through this for you, I'm going to take a shot in the dark. Your description of the problem suggests the value of CCP1 is getting changed at an inopportune time, or the output is being switched to C2 temporarily or there's a bad TRISC or ADCON statement. The most likely cause is that you have a lot of code in your interrupt routine, and you go to it often. It's possible that CCP1 getting set / reset occasionally at unfortunate times because you are off servicing the interrupt. I'd recommend that the interrupt routine set a flag only, or simply increment Tick_Tmr and do the value comparisons (IF..THEN) as part of your main loop.
Just a guess, and maybe a new direction for you to poke.
Henrik, thanks for the reply and suggestion.
The pulsing only occurs when the conditions are matched for the start of the lighting phase. For example, if the lighting period is set for an hour between 10:00 and 11:00, with a 5 minuet fade up and fade down times, this pulsing happens on C.2 when the time is => 10:00 and <=11:00. But the intensity of the LED fades up correctly between 10:00 and 10:05 and down correctly between 10:55 and 11:00. The thing that really perplexes me is that C.1 works as it should with the LED increasing in brightness, stays lit at full brightness and then fades down until turning off at the set times
I seriously believe it's something to do with the port config as Charles has mentioned. It's as if the code is ignoring the configuration of this register.
I did think that the problem may be due to the fact that the RTC uses C.3 and C.4 for SLC and SDA lines but if I have read the datasheet correctly, If bits 3-0 are set to 1100 and bits 6 & 7 are set to 00 then P1B, P1C and P1D are set to port pins, but then these appear to point to pins D5, D6 and D7 rather than Port C pins - so that would rule that out
Given the fact that I can comment out the settings for the register and the code behaves exactly the same way does confuse me (easily done) and the fact that channel 2 works ok and it's channel 1 that is screwing up
If it IS something with the configuration of the port then you should be able to recreate that with less code than you have now.
I don't think I have any 4520's to test and even if I did there's no way I (or I believe anyone else) could recreate your full setup without goig thru a lot of effort.
Have you tried not using the HPWM command and instead setting the dutycycle registers manually?
I haven't yet been able to tell exactly how things are configured on the 4520 but it looks to me as if there's one CCP module and one ECCP module on the 40-pin devices. If that's the case then there might be some differences between them. However, if both modules are of the ECCP module on the 40-pin devices then of course there should be no difference. Obviously only one of them has the bridge drive mode etc (which you don't use anyway).
/Henrik.
Thanks again for the input.
I found an example bit of code on the net
The LED on CCP1CON (pin C.2) still flashes at the same rate as my original code whilst it runs through the loop to fade the LEDCode:ASM __CONFIG _CONFIG1H, _OSC_HSPLL_1H __CONFIG _CONFIG2L, _PWRT_ON_2L __CONFIG _CONFIG2H, _WDT_ON_2H & _WDTPS_512_2H __CONFIG _CONFIG3H, _MCLRE_ON_3H & _LPT1OSC_OFF_3H & _PBADEN_OFF_3H __CONFIG _CONFIG4L, _LVP_OFF_4L & _XINST_OFF_4L ENDASM DEFINE OSC 48 ; config settings 18F4520, 20mhz crystal ADCON1 = $0F clear duty VAR WORD ' Duty cycle value (CCPR1L:CCP1CON<5:4>) TRISC.2 = 0 ' Set PORTC.2 (CCP1) to output CCP1CON = %00001100 ' Set CCP1 to PWM T2CON = %00000101 ' Turn on Timer2, Prescale=4 PR2 = 249 duty = 200 mainloop: CCP1CON.4 = duty.0 CCP1CON.5 = duty.1 CCPR1L = DUTY >> 2 duty = duty + 10 Pause 17 IF (duty < 800) Then mainloop duty = 200 GoTo mainloop
So it must be hardware related. I have a port splitter to allow two connections to the header pins on the EasyPIC5 board, with the RTC module attached to one set of pins on the splitter, and the breadboard connector to the other. As this example code didn't need the RTC I removed that and plugged the breadboard directly to the header pins on the EasyPIC5 board - No more pulsing of the LED, it ramped up over and over again...
So this issue is either hardware related, or the fact the RTC is connected to same port is interfering with the CCP1CON settings...
I therefore breadboarded the RTC chip and connected the breadboard direct to PORTC - It works.... so that's one addon board that will be confined to the bin !! I can't believe that it was a simple bit of hardware that could cause the issue...
Feel like a prat now... thanks Henrik for your assistance - I can now get on with the rest of the project !
Hi,
Glad you've narrowed it down.
What's actually on that splitter board? Is it just passive or are there some buffers or the like on it?
I don't know if RMW can have an impact on the normal I/O-pins or maby if the normal I/O pins can have an impact on the PWM-outputs. Since getting rid of the splitter seems to solve the issue it does sound like a possible RMW issue or capacitive coupling, reflection or whatever.
/Henrik.
Bookmarks