David:
I would suggest when you use the PCA in this manner that you take a slightly different look at how you generate the repetative timing of the output pin. You are currently changing the CH/CL in your interrupt routine. This is not the "typical" way this should be done. The better way is to let the CH/CL counters just free run counting 16 bits as 0000->FFFF in continuous mode. Then you change the CCAP0H and CCAP0L registers on the fly in the interrupt routine to update the time to the next compare/interrupt time. You keep a constant value that represents the half period of your output wave form to be....and each interrupt time you add this count value onto the previous compare value that is in the CCAP0H/CCAP0L registers (ignoring any carry). You can keep track of these "previous" compare values by either reading it directly from the CCAP0H/L registers or by keeping a copy in two byte wide internal memory locations.

Note there is a proper order to be used when updating the CCAP0H/L register pair. I do not recall which it is so look a bit at the data sheet for the PCA. The order comes into play becasue (if done properly) the 16-bit comparator is disabled from the first write through the end of the 2nd write to prevent false compares when the CCAP0H/L are only half updated.

This is the scheme that is normally used as it has two advantages. First, you can generate multiple output frequencies on the various output channels of the PCA. (In your scheme with mucking with the CH/CL you are essentially trying to make a 1 channel only solution.

Secondly, with the scheme I describe there is no jitter on the output frequency due to software latency in the interrupt routine. As you see the timer hardware toggles the output pin and the CH/CL continue to run without accumulation loss relative to actual time the output pin toggled. By the time the interrupt happens and simply updates the compare value we do not care if the CH/CL has rolled past the last compare value by
a variable small amount. Note that it will be important to see that there is a minimum value to the constant value you can add to the compare registers and still get this to work properly. (For example let us say you tried adding 2 to the compare value. If the interrupt latency and interrupt service overhead time caused a delay till the time the capture registers were updated it is possible that the CH/CL values may have already counted past the new compare value you tried to load in the interrupt. This would cause the CH/CL to have to spin all the way back around and give you a much slower output pulse rate than you expected.

This scheme also has the advantage that some PCA channels can then still be used for input capture operations at the same time.

I hope this provides some good info for you.
Used properly the PCA can be used to make very accurate output pulse frequencies without any software induced duty cycle or period jitter.

Michael Karas