Timer is set in edge count mode with an interrupt on match count to update match count value as to increment the timer count value with the number of edges per seconds then converted into RPM to display the speed. The timer block shows 32kHz input into the CCP0/1 pins so it seems it should not have trouble at 202Hz.
If the GPTM timer re-load TnILR value is kept 4 edges ahead of the TnMatchCHR value the timer counts UP and auto reloads at 107hz if TnMatchCHR is unchanged. However a sudden speed up in edge count to 150Hz and the timer appears to quickly stop counting well below the value in TnILR until the edge counts once again become 107Hz. Setting the TnILR load value very high to 1616 edges or { 2 pulses per revolution being 404 pulses x 4 edges @202Hz = 6300 RPM}. 60RPS=60Hz/2PPS/Revolution=30PPS or 1616 edges / 30 = 53PPS at 6300 RPM. So the math formula works back words to prove edge count to RPS to RPM.
Only incrementing the match CHR by 4 edges each interrupt cycle has a worse effect to completely stop the match CHR interrupt. Allowing the count to climb and keeping 4 edges between TnILR - MatchCHR as the count value climbs a very slow increments in debug that doesn't match the realtime edges per-second. The debug values appear to change in 1 second intervals and stops counting within few seconds upon a forces jump in fan speed. The best count achieved is from 1-8 edges per interrupt cycle and renders 253 RPM readout at 107Hz. Seemingly impossible to count edges any faster at higher frequency.
Food for thought 1616 edges per revolution at 6300 RPM = 202Hz square wave being 96,960 edges per minute. According to some folks 6300 RPM appears to resolve to 52.5 pulses per-second so the taco signal is running a bit hot on this fan.
Why is capture edge count not playing nice?
