I've had the same problem as the OP and found this post on the NXP forums which describes my problem (and I think the OP's problem?) well. In any case this ESE page is one of the first sites that appears when searching for PCA9685 flickering LEDs, so I thought I'd add my solution here. From the NXP forum:
Looking at the datasheet
(http://www.nxp.com/docs/en/data-sheet/PCA9685.pdf) fig. 11 on page 20
this looks according to design, the problem is whenever LEDn_ON >
LEDn_OFF and the LEDn_OFF register is updated, the device skips one
whole output phase, switching the output off regardless of the
registers -- look at the empty cycle between "register(s) updated in
this cycle" and "output(s) updated in this cycle". There's no empty
cycle when LEDn_ON < LEDn_OFF as seen on fig. 10 on the preceding
page.
So it isn't an electrical problem, or a problem with the Picobuck (I'm using plain old MOSFETs), it's a problem with the PCA9685 chip itself: keeping the output off for (the remainder of?) a cycle whenever the duty is changed if certain register conditions are met, and if the rising edge is not synchronised with the chip's internal timer.
This poster's final comment was:
Is there a way to avoid this kind of behavior and still benefit from output load balancing?
Spoiler alert: as of writing this there is no answer yet - But this lead me to investigate and try turning off whatever this "load balancing" thing is. I'm using this library for driving it, and after scouring the source I tried changing the declaration of the PCA9685 object found in the sample from this:
PCA9685 pwmController;
to this:
PCA9685 pwmController(Wire, PCA9685_PhaseBalancer_None);
And... Smooth as butter!
So what is load balancing, and why should I care?
Well, it appears to be a way to stagger the rising edge of the PWM signal across each channel, presumably to ease the instantaneous current changes of all 16 channels rising at once and potentially falling at once if the brightness/duty of each channel is equal. The other options in the library are *_Linear which staggers the waveforms by a fixed delay for each channel from the one before it, *_Weaved which interleaves the delays across channels, "balancing the first few outputs better" (whatever that means) and *_Count which is not implemented by the library and works exactly the same as *_None.
Any staggering of the phase results in flickering as soon as levels are changed, and this may also have an effect on particular duty cycle ranges based on the PWM frequency.
Implications I presume are unstable power draw and stronger EMI. I presume this means power should be buffered with a good sizeable cap, but I'm not sure what to do (if anything) about the potential EMI - is it a problem? Is there another issue to consider with turning off phase balancing? If anyone more technical can comment on this, I'd be most grateful.
Best Answer
Quick answer - no, you can't make this work without some hardware changes.
I certainly hope you're not connecting your PICs to 15 volts. They're only rated for 3.6 volts.
Your MOSFET is not an IRL734. It might be an IRF734. In which case, I don't see how you're getting any output at all from the LEDs. What you want to do is connect the top of the LED chain to +12, and the bottom to a resistor. The other end of the resistor goes to the drain of the MOSFET, and the source goes to ground. If you know the operating current and voltage of the LEDs (and I hope you do), then the value of R is
R = (12 - (3 x Vf)) / i, where i is in amps.
Your driver would work (very briefly) if the PIC output were 12 volts, but it's not. I say briefly, because in very short order at least one of the LEDs would burn out. That's why you need a current limiting resistor.
Even with these changes, the circuit may not work well. The problem is that the PIC runs off 3.6 volts (max), while the threshold voltage for an IRF734 is two to four volts. And besides, the IRF734 is a 450 volt MOSFET, which is way overkill.
Given your obvious errors in circuit description (PIC voltage and MOSFET model), I suggest you go back to your source and provide a more complete (and accurate) description.
For what it's worth, 780 Hz is about 10 times faster than you need, but it ought to work just fine.