Tool/software:
Hi TI experts,
SDK:9.2
Linux:9.2
HW:our own board
We use timer16(0x2500000UL) now,the current external crystal oscillator is 19.2m, so the time for one tick is calculated as 1/19200000.We achieve different timer clock accuracies by setting the value of the TIMER_TMAR register, but the actual outcome is not as expected
1. The first version of the software set this count value to 19200, * 1/19200000=1000us=1ms, and the software set the fsync cycle to 33 * 1ms. In this case, the fsync pulse cycle is around 33.1ms or 33.2ms, with an accuracy of 1ms;
2. The second version of the software sets this count value to 1920, * 1/19200000=100us, and the software sets the fsync period to 333 * 100us. In this case, the fsync pulse period is 33.2ms-33.4ms, and the accuracy is inaccurate at 100us;
3. The third version sets this count to 192, * 1/19200000=10us, and the software sets the fsync cycle to 3333 * 10us. In this case, the fsync pulse cycle is a few milliseconds, with an error of milliseconds and an accuracy of 10us that is inaccurate;
4. The final version is the version currently on the server, and the accuracy cannot be adjusted downwards. We have changed our approach and adjusted the accuracy upwards. Based on the original 1ms count value, we calculated it as 1.11, which is equivalent to 19200 * 1.11=21312. The software has set the pulse period to 30 * 1.11ms=33.3ms. Currently, the accuracy has been tested and meets the requirements of their application;
The current issue is:
1. Why does setting the TIMER_TMAR value to 1920 and 21312 result in different results when the clock accuracy is adjusted to 33.3ms?
2. Can the minimum clock accuracy of a timer be 1ms? Is there a way to improve clock accuracy?
3. In addition, we found that even if the TIMER_TMAR register value is set to 21312, a normal 33.3ms pulse period can be achieved. However, in some scenarios with high resource loads, this 33.3ms period may fluctuate and sometimes reach 35ms. Is there any way to stabilize the pulse period at 33.3ms?
BR.
