MCU-PLUS-SDK-AM243X: usage of suitable 64-bit counter for timestamps in HW

Hello,

Felix Heil said:

For the input clocks of the GTC we cann select two PLL-sources. Is there maybe also the possibility of manipulating PLL2 via a divider to generate 1 kHz and use this one as an input for the gtc?

Yes the divider can be configured here. I would suggest you to look through clock tree tool for browsing through the available divider options.

Let me know if you face any doubts/clarifications going ahead with GTC.

Regards,

Vaibhav

Hey Vaibhav,

So I fiddled around with the clocktree-tool but the lowest I can get are around 38 kHz. Best would be a stable 1 kHz, since this will increment a 64-bit-counter every ms. So that's at least what we would need.
Are there other possibilities of having a 64-bit counter which can be incremented every ms, without generating an interrupt every ms at the mcu?

I saw the Timers have push-events. is it maybe possible to configure a timer to a 1 ms-interval and that push-event can increment a 64-bit counter? Also it's stated in the TRM that with a 32kHz-clock it is able to generate a pretty exact 1 ms-interval.

Also the CPTS seems to have a 1 ms-tick which even seems to have some drift-correction.

Best regards

Felix

Hello Felix,

You can go through this response as well: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1377521/faq-processor-sdk-am64x-how-to-create-a-pwm-using-a-timer/5263749#5263749

Let me know if it helps upto some extent.

Apart from this, lets understand your use case piece by piece.

Felix Heil said:

Our current solution is about having a software-timer (from FreeRTOS) which expires every second and we increase a 64-bit variable then. Since our requirements changed and we need ms-resolution we could probably still use this solution, but it would probably be more prone to drift

You mentioned that you were looking at a SW timer approach, which one would you have used? DM TImers/GTC/PMU timers? 

What do you mean by "probably more prone to drift?"

What is the timer threshold value you want, so lets say your 64 bit timer starts from 0 and assuming its a upward counter timer, at what timer value you want the interrupt to be generated?

Felix Heil said:

So we thought about a HWTimer. This is also possible but we will get an interrupt now every ms and we already have some other timers which interrupt every ms

Can you give me an example of HW Timer you are using in your application right which is 64 bit HW Timer?

Felix Heil said:

One possibility would be using another core solely for a timer and putting the timestamp into a shared area. But that seems to be a bit of an overkill.

This will head into shared memory and IPC direction I believe, so we can neglect this as of now. So I believe the other cores will poll this core for issuing timestamp.

Regards,

Vaibhav

Hey Vaibhav,

The "SW Timer" I mean is simply a freeRTOS-Timer. FreeRTOS supports a Timer-functionality, which in the end is a highest prio-task that calls a callback when your configured timer expired. This one can tick in ms. It is our current approach, but we usually used seconds. Now we need to get a higher timestamp-resoulation and thus need a 1ms-tick. The tick then increments a variable. But based on task-scheduling we cannot rely on that timer to be really exact. At least I guess. Also since I want to reduce the task-load I searched for another solution.

The 64-bit-timer I mean can also be viewed as a variable that is increased every 1 ms by 1. I generally do not want it to generate an interrupt every ms at the R5F, since I do not want to spend time blocking other important applications, even if it's pretty short. We already have some applications which use a hw-timer with a 1 ms-tick generating interrupts.
So I am aware of the HW-timers the Sitara supports and we already use them and yes that could be an at least more exact alternative to the SW-timer, but still needs incrementing a variable in SW. So this can be one possibility at least from this point of view.

The point is, we don't need this interrupt, since we do only need to know the timestamp when we are reading it. The routine would not do anything more than just  ++timestamp;

Thw hw-timers of the sitara do only have 32-bit-timestamps. Yes I can cascade them but this is relatively complicated, since we are encapsulating such functionalities in some driver-interfaces.

We are using currently only one existent 64-bit-timer I know, which is the GTC. But this one runs at way higher clocks and thus cannot increment only every 1 ms. We use it currently mainly for benchmarking and measuring our ipc-applications, since GTC is global.

It's good that it supports acces from multiple cores, but that wouldn't even be needed, because we have our own protocol for IPC and time-management and thus only one core needs to have a timer.

So I am just looking for a 64-bit-value in hw that can be incremented every ms without interrupting any mcu but is readable from mcu if needed. I also aw a some possibilities of interconnection in hw but as I mentioned I cannot use a hw-timer to generate a source-clock (in ms) for the gtc, since it's only connected to other clock-sources.

Also you may need to guide me thorugh the lin, since as I understood it's about generating a PWM for a pin and not to internally increments any counter. Or is it somehow possible to route this output to somewhere internal without any hw-modification?

regards

Felix

Hello Felix,

Thanks for the detailed response.

Let me discuss this internally and get back to you.

Regards,

Vaibhav

Hello Felix,

In AM64X there are no 64bit timers except GTC timers.

For your requirement there are two methods.

Method 1 : 

Let you run the GTC at 225MHZ clock and  while reading the GTC time, discord usec values 

Method 2 : 

Please look at the image below.

The GTC clock can be given externally as well.

So, if you feed a 1msec clock to GTC, the GTC can increment at 1msec time .

Regards,

Anil.

hey Anil, thanks for the hint.

yes we also thought about those external sources but we cannot use this for already produced devices. Ok, so we probably use the GTC with a 100kHz or whatever is possible to get a at least millisecond-aligned values. The overhead probably doesn't matter for realistic lifetime of the device.

On the other hand I tried to utilize the 1 ms timer-functionality that is implemented in the sitara timer-modules and described in the TRM. but it seems the TimerP does not support this functionality. when i select the 32k-clock and set the period to a ms, it is counting slower than 1 ms.

I may open another ticket for that topic and go on for now with the GTC.

Best regards

Felix

Hello Felix,

Felix Heil said:

yes we also thought about those external sources but we cannot use this for already produced devices. Ok, so we probably use the GTC with a 100kHz or whatever is possible to get a at least millisecond-aligned values. The overhead probably doesn't matter for realistic lifetime of the device.

For example, we can say that if you are feeding a 1KHz signal external clock to GTC, then the GTC timer is incremented for every 1msec .

Now, you can calculate the overflow time = (2^64 / 1000) sec.

The GTC overflowed at the above time. The above time time is very huge .

Regards,

Anil.

Hey Anil, yes.
I just noticed that all available clock-sources internally are also used for other components. The effort to feed ad least 100 kHz would have to much impact on other clock-consumers. Also we cannot get low as 1 khz with any clock. I think we will stick with a variable in RAM.

best regards

Felix

Hello Felix,

So, the variable is incremented for every 1msec based on RTOS base time .

Regards,

Anil.

Hey Anil,

this will be our default-implementation, but the variable could be incremented by one of the hw-timers of the Sitara. we use both solutions now.