TDA4VE-Q1: VPAC work CLK issue

Hi Biao,

As per the below line, VPAC is running at very less speed at 100MHz. Are you sure that boot pins are properly populated for the 25MHz clock? Because the init code just uses bootpins to figure out the input clock and based on this configures the PLLs.

|   361     |     2    | DEV_VPAC0_MAIN_CLK                                                                | CLK_STATE_READY     | 100000000       |

Regards,

Brijesh

Can you please read the value at the offset 0x43000030 and share it?

Regards,

Brijesh

Hi Brijesh,

The value at 0x43000030 is 0x12B. It looks we are getting the right frequency - 25MHz.

Hi Shawn-Bo,

I suspect somehow PLL is not configured correctly. In order to check this, can you please dump few registers and share their values?

0x00699030

0x00699034

0x00699038

0x00699080

0x00699084

Regards,

Brijesh

Hi Brijesh,

Hi Shawn-Bo,

These PLL configuration is incorrect. Could you please tell me how you are running the example? Have you integrated the DM binary on mcu1_0? Are you running R5 SPL on mcu1_0? Essentially could you please explain your boot flow? 

Regards,

Brijesh  

Hi Brijesh,

Generally speaking, we are following the TI SBL boot flow and change nothing on the flow. The SBL will load tifs and MCU r5f1_0 image when it is loaded by the TI firmware, MCU r5f1_0 will load MAIN_r5f image, c7x image, ATF and Linux stuff then.

Brijesh Jadav said:

Have you integrated the DM binary on mcu1_0?

What is the DM image? I will check this point and feedback later.

Brijesh Jadav said:

Are you running R5 SPL on mcu1_0?

We are running SBL on mcu1_0.

Hi Shawn-Bo,

What's the mcu r5f1_0 binary that SBL is loading? Is it the same as on EVM? 

Also can you please check if Sciclient_boardCfgRm and Sciclient_boardCfgPm APIs are getting called? Because both of these API calls are important and if not called, PLL could be at their reset state. I see most of the PLL25 configuration that you have shared contains reset values.. 

Regards,

Brijesh

Hi Brijesh,

We are using a customized mcu r5f1_0 binary, it is almost the same as what we run on the EVM board for the clock or PLL, we just enabled the SPI on ECU.

Sciclient_boardCfgRm and Sciclient_boardCfgPm APIs are getting called in our mcu code。

Other PLLs configuration except PLL25 are also done in those APIs?

Hi Shawn-Bo,

Can you first try running same mcu2_0 binary as EVM? I am suspecting these APIs are somehow not running. 

Yes, most likely all PLLs are configured in these APIs. are you seeing issues for other PLLs also? or is it just limited to PLL25? 

Regards,

Brijesh 

Brijesh Jadav said:

Can you first try running same mcu2_0 binary as EVM?

Do you mean mcu r5f1_0 here?

As mentioned on the other thread, some clocks are also changing strangely, I'm not sure if the source for those clocks are coming from PLL25 or not, do you have a clock tree then we can find out if they are coming from PLL25 as well?

Hi Shawn-Bo,

shawn-bo zhou said:

Do you mean mcu r5f1_0 here?

Yes, can you please try the same binary that you have used on EVM? 

shawn-bo zhou said:

As mentioned on the other thread, some clocks are also changing strangely, I'm not sure if the source for those clocks are coming from PLL25 or not, do you have a clock tree then we can find out if they are coming from PLL25 as well?

Most of these clocks that you have shared are either coming from PLL25 or PLL19, so we were wondering if any other clock is set properly or not.

Regards,

Brijesh

Hi Brijesh,

I test the mcu r5f1_0 binary which used for EVM before on our ECU, and get the same result with what we have now, the clock is not right.

All the abnormal clocks mentioned on the other thread are coming from PLL25 except the clocks of DSS. The DSS clocks do not change much, maybe they are right, I'm not sure. If they are right, it looks the problem is just limited to PLL25.

It looks something getting wrong in this area. The input reference clock of PLL25 selects WKUP_HFOSC0_CLK, this is what we expected, but the two outputs of PLL25 have really wired values, MAIN_PLL25_HSDIV0_CLKOUT is 66666666Hz and MAIN_PLL25_HSDIV1_CLKOUT is 100MHz. Where is the configuration getting MAIN_PLL25_HSDIV0_CLKOUT and MAIN_PLL25_HSDIV1_CLKOUT?

Hi Shawn-Bo,

Let me check it on EVM, i think i can fix the PLL to 25MHz and check this clock on EVM first.

Regards,

Brijesh

Hi Shawn-Bo,

I am not able to check it on EVM. I thought i could overwrite the DEVSTAT register and tell the SW that it is 25MHz clock, but it is not possible. 

I think we would require debug session to check it why VPAC clock is not getting set. 

Regards,

Brijesh 

Hi Brijesh,

Please let me know if you are available today, I will send you the invitation for the debug session.

Hi Shawn-Bo,

Can we please have this meeting tomorrow 11AM IST? 

Regards,

Brijesh

Hi Brijesh,

Thanks for your time, invitation sent.

HI Brijesh,

Do you get any findings?

Hi Shawn-Bo,

Not yet, we are still looking into it.

Regards,

Brijesh

Hi Shawn-Bo,

Can you please provide some information about this project? For which project are you developing this platform? What's the usecase? 

Regards,

Brijesh

Hi Brijesh,

It is developing for our ADC project (domain controller) now, we will share some designs with VW project, since VW project also use 25MHz external crystal oscillator, this problem may report sooner or later on VW project.

Hi Shawn-Bo,

I think we have fix for this issue (Thanks to Chandru Dhavamani). Can you please make a small change below high lighted change in ti-processor-sdk-rtos-j721s2-evm-08_06_00_11/pdk_j721s2_08_06_00_31/packages/ti/drv/sciclient/src/rm_pm_hal/pm/soc/j721s2/clocks.c file?

const struct clk_default soc_clock_freq_defaults[] = {
CLK_DEFAULT(FREQ_PLLFRACF2_SSMOD_16FFT_MAIN_0_DEFAULT, 1000000000UL, 1000000000UL, 1000000000UL),
CLK_DEFAULT(FREQ_PLLFRACF2_SSMOD_16FFT_MAIN_1_DEFAULT, 960000000UL, 960000000UL, 960000000UL),
CLK_DEFAULT(FREQ_PLLFRACF2_SSMOD_16FFT_MAIN_12_DEFAULT, 2133330000UL, 2133330000UL, 2133330000UL),
CLK_DEFAULT(FREQ_PLLFRACF2_SSMOD_16FFT_MAIN_14_DEFAULT, 2000000000UL, 2000000000UL, 2000000000UL),
CLK_DEFAULT(FREQ_PLLFRACF2_SSMOD_16FFT_MAIN_16_DEFAULT, 2970000000UL, 2970000000UL, 2970000000UL),
CLK_DEFAULT(FREQ_PLLFRACF2_SSMOD_16FFT_MAIN_19_DEFAULT, 1800000000UL, 1800000000UL, 1800000000UL),
CLK_DEFAULT(FREQ_PLLFRACF2_SSMOD_16FFT_MAIN_2_DEFAULT, 1800000000UL, 1800000000UL, 1800000001UL),
CLK_DEFAULT(FREQ_PLLFRACF2_SSMOD_16FFT_MAIN_25_DEFAULT, 2880000000UL, 2880000000UL, 2880000001UL),
CLK_DEFAULT(FREQ_PLLFRACF2_SSMOD_16FFT_MAIN_4_DEFAULT, 2359296000UL, 2359296000UL, 2359296001UL),
CLK_DEFAULT(FREQ_PLLFRACF2_SSMOD_16FFT_MAIN_5_DEFAULT, 2400000000UL, 2400000000UL, 2400000000UL),
CLK_DEFAULT(FREQ_PLLFRACF2_SSMOD_16FFT_MAIN_6_DEFAULT, 1600000000UL, 1600000000UL, 1600000000UL),
CLK_DEFAULT(FREQ_PLLFRACF2_SSMOD_16FFT_MCU_1_DEFAULT, 2400000000UL, 2400000000UL, 2400000001UL),
};

Please rebuild PDK libraries and then SBL to check with the above changes.. I am able to see VPAC clock now being set to 720MHz with the above change. 

I have also raised this issue to our team to get it fixed in the next release.

https://jira.itg.ti.com/browse/SYSFW-6355

Regards,

Brijesh

Hi Brijesh,

It works now, we can get 720MHz with the above change on our ECU.

Thanks a lot for your investigation on this issue.

May I know in which release will this issue be fixed?

Hi Shawn-Bo,

Since this file is auto-generated using internal tools, it will take sometime to get this change incorporated. It will not be part of SDK9.0, which is coming in end of July. Most likely this will be fixed in SDK9.1.

Regards,

Brijesh

Hi Brijesh,

Thanks for the information.