AWR2944: AWR2943

Hello Mohammed,

The formula you mentioned has been implemented in that code as well, the value of that formula will provide it to you in ticks itself:
Lets say for example you have provided the frequency 150 Mhz, then the fRTICLK is 150*10^6Hz
Then if you want it every 1ms, then the fRTIFRCx = 10^3Hz

1) lets take the first formula: RTICPUCx = (150*10^6/10^3)-1 = 149,999 ( theoretically)
2) Lets take the second formula: RTICPUC(ticks) = ((150*10^6)*1000,000)/(1000,000,000) = 150,000 ( Needs to be converted to Hex to be fed to the Register)
Note: The +1 is not included in the second formula as in the implementation the moment it reaches from 0-149,999 it completes the cycle and at 150,000 it increments the cycle by 1.

All the care has been taken you can plug the values and you will get the same result as the formula.

Also, the SDK is for reference, so we have only configured Timer 0, you can implement Timer 1 by using the same as reference.

Hello Saswat,

The 1 needs to be decremented from the register value not incremented, because if you loaded the value as is in the register (like what is happening in the driver) this will lead to one extra cycle taking place each time the up counter will reach the compare up counter value.

Again we have already tested this on 3 different timers, and we were able to see this bug happening, the smaller the timer tick time the higher the drift value. once we decremented 1 from compare up counter the timers values are matching, without it: 3 Timers that started at the same time with different tick values are drifting apart.

Please let me know if the above statements are not clear.

Hello Mohamed,

I understood your concern about the -1, the team is looking into this and will get back to you once team confirms the issue.

Regards,
Saswat Kumar

Hello Saswat,

Any updates regarding this issue?

Hello Saswat,

Has the SDK with the Fix for this problem been released yet?