TDA4AL-Q1: GTC timer counter met issue.

Hi Zekun,

That's surprising. It should not happen. Why don't you use same datatype uint64_t for both variables and for typecasting? 

Regards,

Brijesh

Hi Brijesh

I search the SDK and the app_log_rtos.c file show the default usage of how to get global timer like this:

#define GET_GTC_VALUE64 (*(volatile uint64_t*)(GTC_BASE_ADDR + 0x8U))

static uintptr_t GTC_BASE_ADDR = 0;

GTC_BASE_ADDR = (uintptr_t)GTC_TIMER_MAPPED_BASE;

cur_ts = GET_GTC_VALUE64 / mhzFreq;

Here is the defination of unitptr_t:

/* Types for `void *' pointers. */
#if __WORDSIZE == 64
# ifndef __intptr_t_defined
typedef long int intptr_t;
# define __intptr_t_defined
# endif
typedef unsigned long int uintptr_t;
#else
# ifndef __intptr_t_defined
typedef int intptr_t;
# define __intptr_t_defined
# endif
typedef unsigned int uintptr_t;
#endif

For 32 bit MCU, unitptr_t refers to unsigned int I believe. How to modify this?

Regards

Zekun

Hi Zekun,

In RTOS, appLogGetGlobalTimeInUsec API is used to get the GTC timestamp, and please find below implementation of this API. Essentially, GET_GTC_VALUE64 macro reads on the GTC time and then divides it by 200MHz to get the time in us. 

uint64_t appLogGetGlobalTimeInUsec()
{
uint64_t cur_ts = 0; /* Returning ts in usecs */

if (((uintptr_t)NULL != GTC_BASE_ADDR) &&
(0 != mhzFreq) )
{
cur_ts = GET_GTC_VALUE64 / mhzFreq;
}

return cur_ts;
}

Regards,

Brijesh

Hi, Brijesh

Thanks for details. But regarding customer's usage and issue, how to combine the SDK implementation with customer's?

typedef unsigned long int UINT32;

typedef unsigned long long int UINT64;

#define GTC_TIME_ADDR         (0xA90008U)    
uint64_t a = *(volatile UINT64 *) ((UINT32) GTC_TIME_ADDR);
uint64_t b = *(volatile UINT64 *) ((UINT32) GTC_TIME_ADDR); 

I think it is same as the GET_GTC_VALUE64 macro doing. And now it will trigger the error.

Regards

Zekun

Hi Zekun,

But why do we need to typecast GTC register ?

#define GTC_TIME_ADDR         (0xA90008U)    
uint64_t a = *(volatile UINT64 *) ((UINT32) GTC_TIME_ADDR);
uint64_t b = *(volatile UINT64 *) ((UINT32) GTC_TIME_ADDR); 

One question, when you see this error, can we try to readback the value of GTC counter again and see if it is corrected?

Also can you please check below thread? R5F compiler uses ldrd instruction to read 64bit value, can you check if it is same on customer platform?

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1291230/tda4al-q1-get-gtc-time/4975348#4975348

Regards,

Brijesh 

OK, Brijesh, firstly remove typecast and have a try.

Then use CCS to see if ldrb is used to read register.

Regards

Zekun

Hi， Brijesh

Remove typecast and result still have chance to wrong data.

typedef unsigned long long UINT64;

#define GTC_TIME_ADDR         (0xA90008U)    
uint64_t a = *(volatile UINT64 *) (GTC_TIME_ADDR);
uint64_t b = *(volatile UINT64 *) （GTC_TIME_ADDR); 

uint64_t c = *(volatile UINT64 *) （GTC_TIME_ADDR); 

xxxTimeStamp1 7 fffffff9, 7 000000a4, 6 ffffff03

And result shows  error not only happen in high 32 bit, but also in low 32 bit.

They attach the core and find it is truly ldrd command.

I am think of add a DSB or DBM in front of each read transaction. What do you think?

Regards

Zekun

Hi Zekun,

Yes, ldrd should have helped. Can we try DMB or DSB instruction before accessing this memory?

Regards,

Brijesh

Hi， Brijesh !

add dsb,  the problem is unsolved !  

code 

uart print

I think the problem may not be caused by reading GTC_Reg, may be caused by writing GTC_Reg ! 

Are writing and reading  GTC_Req an atomic operation ?

Regards

Le Zhang

Hi Le Zhang,

But are you writing to GTC register? Sorry i don't see in the above code snippet. 

Regards,

Brijesh

Hi， Brijesh !

No, I am not wrting to GTC register. 

Regards

Le Zhang

ok, let me then check with the team if there is any other solution. 

Hi Zekun,

I checked with the HW team and yes, in this case, R5F should somehow detect the overflow and read the GTC time second time. 

Regards,

Brijesh

Sorry for the delay. Brijesh.

So this issue is unstoppable, right? Are there any way to bypass this, like read double or three times, the last one must be the right value?

Regards

Zeku

Hi Zekun,

Yes, can we please read the GTC registers two times to fix this issue? It would just require additional one GTC clock cycle to come out of this situation. So can we please read this register two times? 

Regards,

Brijesh