AM6548: Wrong ICSSG2 PRU clock speed, when booting from sd-card

Ruediger Wurth

Part Number: AM6548

TI experts,

I have a custom board with Sitara AM6548 where the clocking schema is identical to the IDK board.
We use SYS/BIOS, CCS9.2 and currently processor_sdk_rtos_am65xx_6_01

We run our own PRU program (quite simple one, already stripped down for bug analysis).
When running PRU0 of ICSSG2, I configured CORE_CLK = 200 MHz using the 2 registers described in the TRM:

200 MHz
– CTRLMMR_ICSSGn_CLKSEL[0] CORE_CLKSEL = 1 (CPSWHSDIV_CLKOUT2 is source clock)
– ICSSG_CORE_SYNC_REG[0] CORE_VBUSP_SYNC_EN = 0 (Async Mode, default)

The ICSSG2 PRU program is loaded via the A53 core.
The A53 program contains the PRU program as binary and loads it to ICSSG2.

When I load the A53 program via CCS/JTAG the behavior of the PRU is correct.
But when I boot it from sd-card, the PRU runs with 250MHz instead of 200MHz!

To prove this I have the following PRU code (I did also other measurements, all say the same):

            __R30 |=  (1 << PRU_PIN_SYNC);  // high
            __delay_cycles(200);            // 200 MHz: 200*5ns = 1000ns = 1us
                                            // 250 MHz: 200*4ns =  800ns = 0.8us
            __R30 &= ~(1 << PRU_PIN_SYNC);  // low
            __delay_cycles(200);

On the oscilloscope I see pulses of exactly 1000ns when loading via JTAG and 800ns when booting from sdcard.

I double checked the 2 registers by reading them after startup:
Via UART_printf()

a53>fsitest
FsiTest: initialize PRUs
CFG0_ICSSG2_CLKSEL: 1
ICSSG2_CORE_SYNC_REG: 0

and also via our UART mem dump

a53>mem dump32 0x108048 1
0x00108048: 00000001
a53>mem dump32 0xB22603C 1
0x0B22603C: 00000000

What could be the reason for this too fast PRU CORE_CLK even if the configuration registers are correct?

Best regards,
Ruediger Wurth

over 5 years ago

0 Dave Bell over 5 years ago

TI__Genius 14680 points

Ruediger,

Can you confirm if you are running any GEL scripts in CCS that may be configuring any of the clocks or module initialization when connecting to the core(s)? This could be a difference between what you are executing on the target in your application for JTAG load vs. SDCard boot.

Best regards,

Dave

0 Ruediger Wurth over 5 years ago in reply to Dave Bell

Intellectual 705 points

Dave,

when using CCS/JTAG we use the approach ti\drv\sciclient\tools\ccsLoadDmsc\am65xx\launch.js with disableGelLoad = 1;
There is of course a lot of initialization done by the scripts: DDR, clocking etc

But the CCS/JTAG load is not the problem. We only have the issue when booting from sdcard.
So my suspiction is that either SBL or SYSFW manipulates the register ICSSG_CORE_SYNC_REG of ICSSG2.

A TI collegue gave me the hint that when bit CORE_VBUSP_SYNC_EN has been set and then afterwards cleared, we read it as 0, but the behavior could be like set to 1, because clearing this bit is only valid by a hardware reset:

My problem is now that I cannot find any location where this register is written in SBL (or in SYSFW?).
I searched the complete PDK for the symbolic name CSL_ICSSCFG_CORE_SYNC_REG and also for different hex address values: without success.

Could you try to reproduce this issue at TI side?

Best regards,
Ruediger

0 Dave Bell over 5 years ago in reply to Ruediger Wurth

TI__Genius 14680 points

Ruediger,

Can you step through your board_init and confirm if you're using the PLL configurations defined in <pdk>\packages\ti\board\src\am65xx_idk\am65xx_idk_pll.c (or the same in the EVM directory)?

The default pllcConfigs[] shows the CPSW PLL HSDIV2 to be programmed to 250MHz, which is what drives CPSWHSDIV_CLKOUT2 to the PRU-ICSSG.

>>>

{CSL_CPSW_PLL, PLL_TYPEOF_ADPLLM, 1, 0, 0, 400, 0, 9, 0,
4, 1, 11, 9, 7, 9, 0, 0, 0}, /*250MHz */

<<<

The highlighted number should be 9 (for PLL DCO of 2000MHz divide-by-10 = 200MHz) rather than 7. It could be the load.js is setting for 200MHz as expected, but in your SBL you're using the defaults in the SDK, which look to set to 250MHz.

I'll double-check across the newer revisions and confirm if this is updated.

This is called from board_pll.c in the Board_PLLInitAll() function, which is explicitly programming the PLLs vs. the Board_PLLSetModuleClkFreq() function that is going through the system firmware calls via SciClient.

Best regards,

Dave

0 Ruediger Wurth over 5 years ago in reply to Dave Bell

Intellectual 705 points

Dave,

this was the crucial hint (I couldn't have found this).

I was able to correct our boardlib and build a new SBL.
Now it works fine, thank you!

Best regards,
Ruediger

Processors

Processors forum

AM6548: Wrong ICSSG2 PRU clock speed, when booting from sd-card