TDA4VM: GTC: Setting COUNTVALUE in GTC_CNTCV_LO register is unreliable

felix_123

Part Number: TDA4VM

Tool/software:

Hi TI,

I have a custom board, where GTC is clocked with 62.5 MHz by MAIN_PLL3_HSDIV1_CLKOUT. I am running the following code on R5 in main domain (MCU2_1) in debug mode:

const uint32_t arrayElems = 16;

uint32_t counterValueSet[arrayElems] = {0xF0000000, 0xE0000000, 0xD0000000, 0xC0000000,
                                        0xB0000000, 0xA0000000, 0x90000000, 0x80000000,
                                        0x70000000, 0x60000000, 0x50000000, 0x40000000,
                                        0x30000000, 0x20000000, 0x10000000, 0x00000000};

uint32_t counterValueGet[arrayElems];

for(uint32_t i = 0; i < arrayElems; i++)
{
    HW_WR_REG32(CSL_GTC0_GTC_CFG1_BASE + CSL_GTC_CFG1_CNTCR, 0x0);
    HW_WR_REG32(CSL_GTC0_GTC_CFG1_BASE + CSL_GTC_CFG1_CNTCV_LO, counterValueSet[i]);
    HW_WR_REG32(CSL_GTC0_GTC_CFG1_BASE + CSL_GTC_CFG1_CNTCR, 0x1);
    counterValueGet[i] = HW_RD_REG32(CSL_GTC0_GTC_CFG2_BASE);
}

The values I get for counterValueGet are (2 runs):

0xF0000017 (hex)
0xF000005C (hex)
0xF00000A2 (hex)
0xC0000017 (hex)
0xB0000017 (hex)
0xA0000017 (hex)
0x90000017 (hex)
0x90000067 (hex)
0x70000017 (hex)
0x60000017 (hex)
0x50000018 (hex)
0x40000017 (hex)
0x30000017 (hex)
0x20000017 (hex)
0x10000017 (hex)
0x10000068 (hex)

0xB2E19CE6 (hex)
0xB2E19D2B (hex)
0xB2E19D71 (hex)
0xC0000017 (hex)
0xB0000018 (hex)
0xA0000017 (hex)
0x90000017 (hex)
0x90000067 (hex)
0x70000017 (hex)
0x60000017 (hex)
0x50000017 (hex)
0x50000067 (hex)
0x30000017 (hex)
0x20000017 (hex)
0x10000017 (hex)
0x00000017 (hex)

So sometimes the desired value is captured, sometimes not. Setting the GTC value in the way I am doing it seems to be unreliable therefore.

Adding additional delays like here:

    const uint32_t arrayElems = 16;

    uint32_t counterValueSet[arrayElems] = {0xF0000000, 0xE0000000, 0xD0000000, 0xC0000000,
                                            0xB0000000, 0xA0000000, 0x90000000, 0x80000000,
                                            0x70000000, 0x60000000, 0x50000000, 0x40000000,
                                            0x30000000, 0x20000000, 0x10000000, 0x00000000};

    uint32_t counterValueGet[arrayElems];

    for(uint32_t i = 0; i < arrayElems; i++)
    {
        HW_WR_REG32(CSL_GTC0_GTC_CFG1_BASE + CSL_GTC_CFG1_CNTCR, 0x0);
        for(uint32_t j = 0; j < 32; j++)
        {
            asm("nop");
        }
        HW_WR_REG32(CSL_GTC0_GTC_CFG1_BASE + CSL_GTC_CFG1_CNTCV_LO, counterValueSet[i]);
        for(uint32_t j = 0; j < 32; j++)
        {
            asm("nop");
        }
        HW_WR_REG32(CSL_GTC0_GTC_CFG1_BASE + CSL_GTC_CFG1_CNTCR, 0x1);
        for(uint32_t j = 0; j < 32; j++)
        {
            asm("nop");
        }
        counterValueGet[i] = HW_RD_REG32(CSL_GTC0_GTC_CFG2_BASE);
    }

also does not improve the reliability. The results are the following:

0xE03EA32F (hex)
0xE03EA394 (hex)
0xD0000036 (hex)
0xD000009B (hex)
0xB0000036 (hex)
0xB00000A4 (hex)
0x90000036 (hex)
0x80000036 (hex)
0x800000A5 (hex)
0x80000113 (hex)
0x80000181 (hex)
0x800001F2 (hex)
0x30000037 (hex)
0x20000036 (hex)
0x10000036 (hex)
0x00000036 (hex)

Are you able to reproduce the problem on your side? Do you have any idea on what is wrong in setting the GTC value the way I am doing it? HW_WR_REG32 includes an additional HW_SYNC_BARRIER (dsb instruction) which does the following (excerpt from Crtex R5 TRM:

"This instruction forces the processor to wait for all pending explicit data accesses to complete before any additional instructions stages can be executed. There is no effect on pre-fetching of instructions."

So in my understanding, HW_WR_REG32 should only return when the value is actually written.

Thanks and best regards,

Felix

6 months ago

0 Brijesh Jadav 6 months ago

TI__Guru**** 478575 points

Hi Felix,

but could you help me understand why you want to write the GTC cnt register? Do you want different start than 0? Any specific reason?

Regards,

Brijesh

0 felix_123 6 months ago in reply to Brijesh Jadav

Expert 1251 points

Hi Brijesh,

thanks for your quick reply.

The use case is the following: I want to run GTC on two TDA4 synchronously.

Therefore both GTC are sourced with EXT_REFCLK1, which is the same source for both of them. Since GTC has the flaw, that reading/writing when there is no clock available results in a crash of the system, I am using an additional HW Timer (which also has EXT_REFCLK as input clock) as a proxy. At some time later, I adopt the current value of the Timer into GTC using the code provided above.

If adopting the timer value is not working reliably, we have to search for another solution. But it would be great if you could confirm the same behaviour on your side and maybe give some insights on why this happens and how to avoid it.

Best regards,

Felix

0 felix_123 6 months ago in reply to felix_123

Expert 1251 points

Hi TI,

just a quick reminder, so that this issue is not closed automatically.

Regards,

Felix

0 Brijesh Jadav 5 months ago in reply to felix_123

TI__Guru**** 478575 points

Hi Felix,

But then how do you synchronize the hw timer that you want to use as proxy? Also if the timer is also sourced from the same clock source, are you able to access the registers?

In general, accessing and setting GTC value from two different TDA4 at the same time could be difficult.

Regards,

Brijesh

0 felix_123 5 months ago in reply to Brijesh Jadav

Expert 1251 points

Hi Brijesh,

Both timer are enabled and set to EXT_REFCLK1. At this time, there is no clock on EXT_REFCLK1. At some point later in time, the clock on EXT_REFCLK1 is activated and both timers are starting to count synchronously.

I am not able to apply the same idea on GTC since TDA4 crashes, if someone wants to read from GTC when there is no valid source clock and I can not guarantee that no one is reading theses registers within that short period of time.

Setting GTC value does not have to be at the same time. Since the HW timer are counting synchronously, I can read their value anytime and set GTC accordingly. The only problem is, that setting GTC this way seems to be unreliable.

Best regards,

Felix

0 Brijesh Jadav 5 months ago in reply to felix_123

TI__Guru**** 478575 points

Hi Felix,

ok, yes, if there is no clock provided, GTC register can potentially cause crash.

Regards,

Brijesh

0 felix_123 5 months ago in reply to Brijesh Jadav

Expert 1251 points

Hi Brijesh,

thanks for confirmation. Were you able to reproduce the initial issue on your side? Or do you have a workaround which solves the mentioned "unreliability"?

Best regards,

Felix

0 Brijesh Jadav 5 months ago in reply to felix_123

TI__Guru**** 478575 points

Hello Felix,

What unreliability do you mean here? Can you please elaborate?

Regards,

Brijesh

0 felix_123 5 months ago in reply to Brijesh Jadav

Expert 1251 points

Hi Brijesh,

the "unreliability" is explained in my initial post. Please read this one again carefully.

Best regards,

Felix

0 Brijesh Jadav 5 months ago in reply to felix_123

TI__Guru**** 478575 points

Hi Felix,

Are you checking this code in standalone environment? Is there anything else running in parallel?

Regards,

Brijesh

0 felix_123 5 months ago in reply to Brijesh Jadav

Expert 1251 points

Hi Brijesh,

the A72 is running Linux in parallel. Do you think, that this should have an effect on setting the GTC register?

Best regards,

Felix

0 Brijesh Jadav 5 months ago in reply to felix_123

TI__Guru**** 478575 points

Hi Felix,

no, i mean on the core where you are running this code? Is there anything else running in parallel?

Also if not running in parallel, where is the code running from? DDR? Is it possible to move this code to some internal memory and then check the GTC output?

Regards,

Brijesh

0 felix_123 5 months ago in reply to Brijesh Jadav

Expert 1251 points

Hi Brijesh,

no, there is nothing running in parallel.

Initially, the code was running from DDR. I put the code now into TCM, but this did not have an effect on the results.

Best regards,

Felix

0 felix_123 4 months ago in reply to felix_123

Expert 1251 points

Hi Brijesh,

Do you have any other suggestion on how to avoid the unreliability in setting the GTC to a custom value?

Best regards,

Felix

0 Brijesh Jadav 4 months ago in reply to felix_123

TI__Guru**** 478575 points

Hi Felix,

Due to priority issues, i could not check this. Let me think over it and get back to you next week.

Regards,

Brijesh

0 Brijesh Jadav 3 months ago in reply to Brijesh Jadav

TI__Guru**** 478575 points

Hi Felix,

Is this thread still open?

Regards,

Brijesh

Processors

Processors forum

TDA4VM: GTC: Setting COUNTVALUE in GTC_CNTCV_LO register is unreliable