Any power supply connected to a source impedance that is variable and often higher than its own must modify its operation to match impedances as closely as possible for maximum efficiency.  This design uses duty cycle for impedance matching and works as follows (refer to the peripheral config schematic for details).

The hardware control loop, consisting of an inner peak current and outer voltage loops, runs without interference from the firmware.  The comparator output from that loop drives a falling event to the COG that sets duty cycle.  The maximum duty cycle of the unit is governed by the master PWM and also generates a falling event to the COG.  The COG works on a first come, first serve, basis:  the first falling event ends the DC (subsequent events are ignored).  Under normal circumstances (without MPPT & low source impedance), the HW control loop would always generate the falling event.

The MPPT firmware manipulates the maximum allowable DC by modifying the master PWM's DC.  When the PV output is low (high impedance), it will set a low maximum DC.  Regardless of what the HW control loop demands the master PWM will terminate the DC first.  During periods of high PV production (low impedance) and/or loads less than 
available energy, the master PWM DC will be set high and the HW control loop will terminate the DC.  Of course the side effect of this scheme (or any that manipulates the power supply's impedance) is that the output voltage will often be less than what the HW control loop demands.

The algorithm consists of two sections.  The first moves the duty cycle a fixed increment, defined by S_TM_MPPT_DC, in the direction indicated by the bit flag mpptIncrease when the bit flag mpptMove is set TRUE.  Evaluation of the results of moving the DC is handled by the second section.

When the DC is moved there is a mandatory delay defined by constant 
S_LM_MPPT_COUNT which specifies the number of RUN loop iterations that must complete.  This is done to reduce jitter and 'hunting'.  Because it uses loop iterations and not a fixed timing source it's important to know the average loop execution time since this forms a primitive filter.  This can be measured by uncommenting the constant
_TIMING_RUN in mpptproto.h and probing one of the LED pins.

When the timer expires the current PV power is compared to the MPPT's previously sampled power.  If less the DC direction is reversed since it's assumed that the peak was passed.  If equal, no change is made and a new delay/sample taken.  This method creates a sweeping motion over the available PV power range.

Even in static conditions the algorithm hunts.  Adding hysteresis (similar to the fault monitoring method) would likely help.