Did I miss something...
Ignore the MCC warning. It's irrelevant, if slightly annoying. (See Footnote.)
I'm assuming that you set up Timer 1 as a synchronized counter, since that's what the Data Sheet says to do.
And I'm assuming that you set the CCP1 mode to 0b0001 (Toggle CCP output and reset Timer1).
Well here's the deal...
When Timer 1 reaches a count value equal to the contents of CCPRH and CCPRL a reset signal is issued to Timer 1. But (and this is a Big But), since Timer 1 is synchronized, it doesn't get reset until the next TCK1 rising edge. For that time (i.e. a complete cycle of TCK1 input) the CCP1 comparator matches TMR1 and the output toggles every Fosc/2 period (Output is toggling at 8 MHz, which generates a 4 MHz square wave during that time, right?)
Upon reflection, I think it has nothing to do with operating in synchronized mode. Here's what makes it act that way, according to the Data Sheet:
Note: In Counter mode, a falling edge must be
registered by the counter prior to the first
incrementing rising edge after any one or
more of the following conditions:
• Firmware writes to TMR1H or TMR1L
In other words (I think) after writing to TMRH or TMR1L it must wait until the next rising edge of its clock to take effect. Presumably this applies to the "reset" signal from the CCP. At least that's consistent with what we observe with this CCP mode.
Bottom line: I don't think the compare mode is useful if you are expecting the CCP1 output to toggle exactly once every time Timer 1 reaches the specified value.
A suggestion: Don't use the CCP output (i.e. don't map it to a pin). Enable the CCP interrupt and in the CCP ISR toggle a GPIO output pin. (It works for me for my PIC16F18857---only one interrupt is generated for each match.)
That might give some insight into the operation of the CCP module, but if you are going to do something that requires program intervention, you could just use Timer 2, 4, or 6 to generate a periodic interrupt and have its ISR toggle the output pin.
Due to the nature of interrupt-driven output, there will be a little jitter in the output for either of these two methods. Of course, since the input clock is (presumably) asynchronous with respect to the system clock, the output will necessarily have some jitter, so I don't think the interrupt stuff will add significantly, but I don't know what your actual requirements are.
On the other hand, a cleaner approach, not requiring interrupt or other program intervention, might be to consider using a CLC/NCO combination to do the deed if you haven't already used the required resources for other things. (I think that might work, but I haven't tested it.) Note that the NCO output itself may be jittery (that is the nature of this type of signal genaration), so, depending on your requirements, that might not be more suitable than the interrupt/toggle approach of the previous paragraphs. Maybe it's worth a shot...
I have started using MCC in certain evaluation projects. Sometimes it seems like a shortcut to initialization.
I mean, MCC can sometimes help us get things set up, but I, personally, can not say that I ever attained "insight" from the use of MCC.
post edited by davekw7x - 2018/08/21 23:39:29