Re: Issue with Timer config
Similar issue, different processor. Context, Core 4.85, MPLABX IDE 5.30, Processor 16LF15356. Timer mode 16bit.
When setting up a timer 0 to run on unsync LPINTOSC for a timeout of 60 seconds the config module gets is completely incorrect. For anything beyond Postscale 1:1 the output is not calculated. Note my representation of the TMR0 value is as a 16bit value, I am aware this is actually two 8bit registers (TMR0H/TMR0L).
Example (from my 60 second timer:
Prescale 1:32, Postscale 1:1 Actual shown as 60s, suggested (Registers tab) TMR0 value 0x1CF3, Correct
Prescale 1:16, Postscale 1:2 Actual shown as 67.64903s, suggested (Registers tab) TMR0 value 0x0000, Incorrect. (Correct value is same 0x1CF3)
Another example (as 2 second timer)
Prescale 1:2, Postscale 1:1, Actual shown as 2s, suggested (Registers tab) TMR0 value 0x86E8, Correct
Prescale 1:1, Postscale 1:2, Actual shown as 4.114s, suggested (Registers tab) TMR0 value 0x0000, Incorrect
So basically because it can't handle the postscale value MCC makes the TMR0 value 0x0000 and then calculates the actual time as being full scale. It is also not reliant on the clock source selected.
I have resorted to using an excel sheet (for this project) to calculate the correct timer values. Also I am also not reliant on the value that MCC produces as I am swapping and changing timer modes etc throughout my code. MCC mostly provides a quick (usually) method of obtaining the values as I can swap and change the various settings and then just grab the values from the registers page when I am happy.
I have not tried other cores or other processors, I did try Timer 2 on this, it works correctly however this has a much different configuration and as such the result is probably calculated differently.
I did try Timer0 as 8bit mode and as this then uses TMR0H as the equivalent of PR0 (a period register rather than an overflow register) and this does work correctly (desired timeout is set as 10ms). Swapping the Pre and post scalers produces the correct values (for TMR0H).
Conclusion is that for 16bit mode the calculation is broken.