J784S4XEVM: GTC spin time does not match the configured frequency

Jim Zhang

Prodigy 200 points

Part Number: J784S4XEVM

Tool/software:

In my j784S4 EVM board, GTC clock is configured by CTRL_MMR0_CFG0::CFG0_GTC_CLKSEL as MAIN_PLL3_HSDIV1_CLKOUT:

The MAIN_PLL3 clkout is 1GHz:

The HSDIV1 for MAIN_PLL3 is 7

So the GTC frequency is: 1GHz/(HSDIV1+1) = 125MHz

I use following spin_time function to spin some time basing on the GTC frequency:

void spin_time(u32_l20_t wait_time)
{
uint64_t ts_start;
uint64_t ts_curr;
uint32_t time_period;

uint64_t time_ran;

time_period = gtc_get_period(); /* Returns in Seconds left shifted by 40,

verified that period matching 125MHz */

ts_start = gtc_counter_get64();

do
{
ts_curr = gtc_counter_get64();

time_ran = ((uint64_t)(ts_curr - ts_start) * time_period) >> 20u;
}while (time_ran < ((uint64_t)wait_time));

return;
}

but I only get half of the spin time I setup. The time when I step from line 77 line 78, it expects to be 40ms, but I always get about half of the number it supposed to get

I have tested with different like 10ms 500ms, 1s, and always get about half of them spined.

There is another issue that: even I set CNTCT.HDBG=1, gtc counter is supposed to freezing when I stop in debugger, but it keeps increasing

How can we stop the counter ticking during debugging ?

6 months ago

0 Neehar Sawant 6 months ago

TI__Mastermind 20360 points

Hi Jim,

Let me look further into to your spin_time function implementation and get back to you.

Jim Zhang said:
There is another issue that: even I set CNTCT.HDBG=1, gtc counter is supposed to freezing when I stop in debugger, but it keeps increasing

How can we stop the counter ticking during debugging ?

I have re-attached the text file I had provided previous which includes instructions on how to halt GTC on line 27. GTC is mapped to slot 0 similar to MCU TIMER is mapped to slot 105. Additionally, note step 2 where you can set the bit manually as you have done or add it to the CMM script as well.

Fullscreen 4520.cpu-suspend-mapping.txt Download

Peripherals can be frozen when a core is put into debug halt if a suspend
signal is associated between a core and a peripheral.  This can be useful
for debug of peripherals that have running timers, watchdogs, or DMAs.

1: The first step is to associate a CPU's debug entry with a peripheral:

Suspend CPU mapping:
============================
Suspend Router: @APB:0x9D300000 | @AXI:0x4C:0x3D300000

CPU Suspend Input mappings:
-----------------------------
0     => unused
1-8   => A72-0, A72-1, ..., A72-7
9-12  => C7x-0, C7x-1, C7x-2, C7x-3
17,18 => MCU-R50, MCU-R51
19,20 => MAIN0-R50, MAIN0-R51
21,22 => MAIN1-R50, MAIN1-R51
23,24 => MAIN2-R50, MAIN2-R51
30    => SMS-CM4_0 (TIFS)
31    => SMS-CM4_1 (HSM)

Peripheral Outputs (0-127 slots):
----------------------------------
main timers main_0 to main_19 are mapped to slots 16 to 35
mcu timers mcu_0 to mcu_9 are mapped to slots 105 through 114
gtc is mapped to slot 0 (gtc feeds multiple clocks, eg: A72-arch-timer)

MCU-TIMER0 is in slot 105 (105+1) x 4 = 424 = 0x1A8
  @APB:0x9D3001A8         - debug address plane
  @AXI:0x4C:0x3D3001A8    - 64bit-system address

stop timer if "MCU-R50" is halted by writing:
  Data.Set EAPB:0x9D3001A8 %LE %Long (0x10000|17.)
  or Data.Set AXI:0x4C:0x3D3001A8 %LE %Long (0x10000|17.)

stop timer if "A72-0" is halted by writing:
  Data.Set EAPB:0x9D3001A8 %LE %Long (0x10000|1.)
  or Data.Set AXI:0x4C:0x3D3001A8 %LE %Long (0x10000|1.)

2: The second step is to enable the peripheral to react to the suspend signal.
Many peripherals have a 'freeze' or halt bit control in their register space.
For example, for the GTC, GTC_CNTCR.HDBG[1] needs to be set.
 Data.Set EZAXI:0x00A90000 %LE %Long 0x3
For a TIMER a TICOP_CFG.EMUFREE flag needs to be cleared

Thanks,

Neehar

0 Jim Zhang 6 months ago in reply to Neehar Sawant

Prodigy 200 points

The HDBG bit is working now, thank you.

Just for your info, the spin time code implementation should be OK. I have been testing it over years with different processors from various vendors, working fine for other processor. The focus might be on the clock frequency

0 Neehar Sawant 6 months ago in reply to Jim Zhang

TI__Mastermind 20360 points

Hi Jim,

With GTC_CLKSEL_clk_sel[3:0] set to 000 the GTC clock will be selected as MAIN_PLL3_HSDIV3_CLKOUT as you said.

Given your HSDIV value of 7, the expected GTC frequency is actually 2000 MHz / 8 = 250 MHz.

Jim Zhang said:
The MAIN_PLL3 clkout is 1GHz:

Where did you see this value?

Thanks,

Neehar

0 Jim Zhang 6 months ago in reply to Neehar Sawant

Prodigy 200 points

How did you get 2GHz from MAIN_PLL3 ? From the config below, it is 1GHz

Here is the calculation:

MCU_SYSCLK0
	HEX	DEC	FOUT	FOUTPOSTDIV
			(FREF/REFDIV)*(FBDIV+FRAC>>24)	FOUT/(DIV1+DIV2)
FREF		19200000	2000000000.38	1000000000.19
FBDIV	0x68	104
FRAC	0x2AAAAB	2796203
REFDIV	1	1
DIV1	1	1
DIV2	1	1

GTC clock is not using the FOUTPOSTDIV ? is it using the FOUTP or FOUTN in the table below?

0 Neehar Sawant 6 months ago in reply to Jim Zhang

TI__Mastermind 20360 points

Hi Jim,

I will follow up and clarify everything tomorrow.

Thanks,

Neehar

0 Jim Zhang 6 months ago in reply to Neehar Sawant

Prodigy 200 points

There is another issue with the GTC counter:

If I enable data cache, the GTC counter stops; I have to disable the data cache, then the gtc counter is ticking. Why DCACHE status impact GTC ?

Is there gtc test app in sdk ? I can reproduce the issue using TI example if there is a gtc test app

0 Neehar Sawant 6 months ago in reply to Jim Zhang

TI__Mastermind 20360 points

Hi Jim,

Sorry for the delay as I have had low bandwidth.

Jim Zhang said:
GTC clock is not using the FOUTPOSTDIV ? is it using the FOUTP or FOUTN in the table below?

Main PLL3 does not have FOUTPOSTDIV output and GTC uses output from FOUTP going through the Main PLL3 HSDIV. Your calculations are correct for FOUT which is 2GHz and Main PLL HSDIV1 which is used for GTC will divide by PLL3_HSDIV_CTRL1[0:6] + 1 which is actually 2000 MHz / 8 = 250 MHz for your case.

Additionally, FOUTPOSTDIV = FOUTP / (POSTDIV1 * POSTDIV2) and you have calculated by POSTDIV1 + POSTDIV2 in the denominator.

Are you using TISCI for clock setup? Your register values differ from my setup and the information I previously provided was assuming you are using TI SCI.

Additionally, if you have set up the clock manually, please ensure it is within the operating frequency provided below.

Jim Zhang said:
If I enable data cache, the GTC counter stops; I have to disable the data cache, then the gtc counter is ticking. Why DCACHE status impact GTC ?

We do not have any GTC test applications within the PDK. Sorry I am not familiar with this bit. What register is this part of?

Lastly, what is your use case for this?

Thanks,

Neehar

0 Jim Zhang 6 months ago in reply to Neehar Sawant

Prodigy 200 points

Data cache is a bit in SCTLR. It is a very basic control register. App enables instruction cache and data cache to improve performance. Icache enable does not have any issue, but when I enable d-cache, the gtc is not ticking any more

Here is the test results when dcache enabled:

check point 1: runtime 69.ms

check point 2: continue run from runtime 69 ms to 4.5s, gtc counter is not ticking, stays same counter

GTC was running before it hits the break point; after that it does not update any more.

If dcache is disabled, gtc counter is updating properly.

The app is exactly same, only the SCTLR.C bit is enabled or disabled.

I have uploaded the elf for you to compare. test_binaries.zip

I don't think any app logic can cause this issue

0 Jim Zhang 6 months ago in reply to Neehar Sawant

Prodigy 200 points

Neehar Sawant said:
Are you using TISCI for clock setup? Your register values differ from my setup and the information I previously provided was assuming you are using TI SCI.

I use the flash scripts to setup the clock. How do you setup the clock to the right state ? For an r5f app that does not have bootloader, what is the recommendation from TI to setup clock ? From TI startup code, I did not find the info for clock setup, SRAM, DRAM etc

0 Neehar Sawant 6 months ago in reply to Jim Zhang

TI__Mastermind 20360 points

Hi Jim,

Jim Zhang said:
Data cache is a bit in SCTLR. It is a very basic control register. App enables instruction cache and data cache to improve performance. Icache enable does not have any issue, but when I enable d-cache, the gtc is not ticking any more

This query seems to be deviating from the thread title, could you please create a new thread for this? I can assist you there.

Jim Zhang said:
I use the flash scripts to setup the clock. How do you setup the clock to the right state ? For an r5f app that does not have bootloader, what is the recommendation from TI to setup clock ? From TI startup code, I did not find the info for clock setup, SRAM, DRAM etc

Are you running FreeRTOS with SBL? Or running baremetal with GEL to CMM script?

Thanks,

Neehar

0 Jim Zhang 6 months ago in reply to Neehar Sawant

Prodigy 200 points

Neehar Sawant said:
Are you running FreeRTOS with SBL? Or running baremetal with GEL to CMM script?

I am running freertos with GEL to CMM scripts. I do not have bootloader. SBL for mcu R5F is part of u-boot on A72? Where is the SBL stored ?

0 Neehar Sawant 6 months ago in reply to Jim Zhang

TI__Mastermind 20360 points

Hi Jim,

The GEL to CMM scripts should set up the PLLs and clock properly. Are you currently having any issues with your clock?

Jim Zhang said:
Where is the SBL stored ?

SBL in generally stored with the boot media depending on the situation. For example, with SD card boot it is stored on the BOOT partition as tiboot3.bin.

Do you still have troubles with GTC? Can this thread be closed?

Thanks,

Neehar

0 Jim Zhang 6 months ago in reply to Neehar Sawant

Prodigy 200 points

The GTC stopped ticking issue after debugging. I doubt it is debugger issue. I have uploaded the binary in this thread. If you can load the elf using your debugger, and check if gtc is still ticking after stopped at breakpoint.

I already prepared the material and uploaded them to this thread. If I create a new thread, I need prepare those info and uploaded again. We can solve the issue in this thread. It is still GTC issue

0 Neehar Sawant 6 months ago in reply to Jim Zhang

TI__Mastermind 20360 points

Hi Jim,

Is this regarding the DCACHE bit?

What is the use case for manipulating this bit?

Thanks,

Neehar

0 Jim Zhang 6 months ago in reply to Neehar Sawant

Prodigy 200 points

Usually we enable DCACHE in startup for performance, it is not changed after. The issue is: When dcache is enabled at startup, GTC is not ticking after debugger breaks/resumes the execution; if dcache is not enabled at startup, gtc continue ticking after debugger breaks/resumes the execution

0 Neehar Sawant 5 months ago in reply to Jim Zhang

TI__Mastermind 20360 points

Hi Jim,

How are you configuring the GTC? Can you provide the code?

Are you using code from the PDK or custom application?

Thanks,

Neehar

0 Neehar Sawant 3 months ago in reply to Neehar Sawant

TI__Mastermind 20360 points

Hi Jim,

Following up, is this issue still open?

Thanks,

Neehar

0 Jim Zhang 3 months ago in reply to Neehar Sawant

Prodigy 200 points

The issue is still there: when dchache is enabled, if I break the program from debugger, the GTC counter is frozen, and does not tick any more. I think it is a dache refresh issue, but not sure it is caused the debugger, or some of the dcache refresh configuration missed in r5f setup.

0 Neehar Sawant 3 months ago in reply to Jim Zhang

TI__Mastermind 20360 points

Hi Jim,

How are you configuring the GTC?

Are you using custom code or from the PDK?

Thanks,

Neehar

0 Jim Zhang 3 months ago in reply to Neehar Sawant

Prodigy 200 points

I will try to reproduce the issue from an sdk app

0 Neehar Sawant 3 months ago in reply to Jim Zhang

TI__Mastermind 20360 points

Thanks Jim, I will wait for your findings.

Thanks,

Neehar

Processors

Processors forum

J784S4XEVM: GTC spin time does not match the configured frequency