AM263P4: ECP: AM263P4 Jitter flag is getting set after configuring PLL CORE

Hi Sanith,

Can you please confirm which clock source and clock divider settings you're using here for your custom OSPI boot project? Basically clock source is critical here, if that's jittery, then it can affect the clock of the entire SoC.

Best Regards,
Mayank Shadwani

Hi Mayank Shadwani 

Thanks for your response....

I'm using External Oscillator as reference clock source for both PLL_CORE and PLL_PER. (TOP_RCM_PLL_REF_CLK_SRC_SEL Register value is 0x00000000)

I followed steps mentioned in "6.4.7.1.1.2 Sequence to Configure the CORE PLL"

and the register dump values are

Hi Sanith,

Thank you for sharing the register dump.

I can see the issue from your register values:

Sanith goud Kothuri said:

TOP_RCM_TOP_RCM_PLL_PER_STATUS

0xC0001618

TOP_RCM_PLL_CORE_STATUS bit 6 is showing 1'b0, which indicates PLL_CORE_STATUS_LOSSREF (Reference input loss). Similarly, TOP_RCM_PLL_PER_STATUS shows the same issue. Please refer to Table 2-588 of AM261x Register Addendum (https://www.ti.com/lit/ug/spruj94a/spruj94a.pdf#page=410).

Both your PLLs (CORE and PER) are not receiving a valid reference clock from the external oscillator.

Best Regards,
Mayank Shadwani

Hi Mayank Shadwani 
How to resolve this issue, can u you suggest any steps ?

Im following the steps mentioned in TRM "6.4.7.1.1.2 Sequence to Configure the CORE PLL" and reg dump values are compared with SDK example project almost all are same except some registers.

Since SDK SBL example project is working fine, so I'm assuming that XTAL 25Mhz is working fine .

Any suggestion to debug.

Hi Sanith,

Thank you for sharing the details. Since the SDK SBL example project is working fine on your board, that's a good indication that the 25MHz crystal oscillator is functioning. However, the jitter flag being set suggests there might be intermittent noise or instability on the reference clock that's affecting PLL performance. Before we proceed further with software debugging, I'd like to rule out any potential hardware issues first.

Could you please probe the external 25MHz oscillator output directly using an oscilloscope and verify the signal quality? When you probe the oscillator, you should observe a differential sine wave. Please check that it's a clean sine wave without any distortion, noise, or irregularities. Even if the oscillator is working well enough for the SDK example to boot, marginal signal quality could still cause the jitter flag to assert during PLL lock, especially if there are differences in PCB layout, power supply quality, or loading conditions between different sections of your design. Look for any distortion on the sine wave or periodic disturbances that might indicate power supply noise coupling into the clock path.

Additionally, I need some clarification on your setup to better understand the issue. First, is this jitter flag issue seen on only one device or are you observing this across all units? If it's isolated to specific boards, that would point toward a hardware variation or assembly issue. Second, are you using a custom PCB or TI's EVM? This is important because if you're using a custom board, we need to verify that the PCB layout around the oscillator, power supply decoupling, and clock routing follows the recommended guidelines from the hardware design guide. Sometimes even small deviations in PCB design can cause clock quality issues that manifest as jitter flags.

Once we have the oscilloscope measurements and information about your hardware setup, we can determine whether this is a hardware signal integrity issue that needs to be addressed in your PCB design, or if there's something specific in your PLL configuration sequence that needs adjustment. Please share the oscilloscope screenshots of the 25MHz clock signal along with the answers to the questions above, and we can take it from there.

Best regards,
Mayank Shadwani

Mayank Shadwani said:

Please share the oscilloscope screenshots of the 25MHz clock signal

above is the oscilloscope screen shot, i probed at one of the pad of R178 which is XTAL_IN

Mayank Shadwani said:

I need some clarification on your setup to better understand the issue. First, is this jitter flag issue seen on only one device or are you observing this across all units?

I can see this jitter flag issue on two different CC boards.

Mayank Shadwani said:

Second, are you using a custom PCB or TI's EVM? This is important because if you're using a custom board, we need to verify that the PCB layout around the oscillator, power supply decoupling, and clock routing follows the recommended guidelines from the hardware design guide.

As of now I'm using TI's AM263Px Control cards, later we will procure our custom PCB

Hi Sanith,

Thank you for sharing the oscilloscope screenshot. There are visible bumps and distortions on the sine wave, which is definitely not normal behavior for a crystal oscillator. A healthy 25MHz crystal should produce a clean, smooth sine wave without any irregularities or distortions like what you're observing. These bumps on the waveform indicate that your crystal oscillator is not functioning properly and is likely degraded or damaged. This would explain why the PLL is detecting jitter and setting the jitter flag in the status register. I probed the same signal on our setup here, and I'm getting clean sine waves without any such distortions.

Before we conclude that the crystal needs to be replaced, I want to rule out one other possibility related to your hardware configuration. Can you please verify and confirm that you have correctly populated R178 and R179 and have depopulated R176 for using the crystal oscillator? 

If you can confirm that R178 and R179 are populated, R176 is depopulated, and the crystal circuit matches the reference design, then the crystal itself has likely failed and needs to be replaced with a known good component. Once you replace the crystal, the waveform should be clean, and the PLL jitter flag should clear. Please let me know the outcome after verifying the hardware configuration.

Best regards,
Mayank Shadwani

Mayank Shadwani said:

Before we conclude that the crystal needs to be replaced, I want to rule out one other possibility related to your hardware configuration. Can you please verify and confirm that you have correctly populated R178 and R179 and have depopulated R176 for using the crystal oscillator? 

From control card schematics, they are saying R179,178 shouldn't be populated and R176 is of zero Ohms.

The same i can see on the Control card that is R179,178 pads are empty and no resister is mounted on the board and i can see R176 pad is mounted with resister.

Mayank Shadwani said:

then the crystal itself has likely failed and needs to be replaced with a known good component. Once you replace the crystal, the waveform should be clean, and the PLL jitter flag should clear. Please let me know the outcome after verifying the hardware configuration.

but the same board it working fine with SDK SBL example project and jitter flag is zero.

this SDK example code TOP RCM register values

with the help of SDK SBL project,I probed the OSPI clock signal with the help of TP 32, i can see OSPI clock is 133MHz

but when i load my custom boot loader, during PLL initialization i got jitter flag set and i shared the TOP RCM register dump with you above

then i probed the OSPI CLK with help of TP32, i can see 56 MHz signal on oscilloscope.

Things are working fine with SDK SBL code, but not with my custom SBL project enough though the sequence of initializing is as per TRM

Hi Sanith,

Thank you for the detailed information. Before we proceed with comparing the register configurations, I need to clarify one important thing to ensure we're comparing apples to apples. You mentioned that the SDK SBL example is working fine on your board, but I need to confirm whether the SDK example is also configured to use the external clock source (like your custom bootloader) or if it's configured differently. Can you please capture the same oscilloscope screenshot at the same probe point when running the SDK SBL example? This will help us verify that both the SDK and your custom code are using the same clock source configuration. If the SDK is using a different clock source or if the waveform looks different, that would explain the discrepancy.

Additionally, to help identify where your PLL initialization might be diverging from the working SDK implementation, could you please share your exact PLL programming sequence? I need to see the step-by-step register writes you're performing in your custom bootloader, including the register addresses, values being written, and the order in which they're being programmed. Please share your actual code snippet or a detailed sequence of register operations so I can compare it against the TRM sequence and the SDK implementation to identify any potential issues with timing, register values, or sequence order that might be causing the jitter flag to be set and the incorrect OSPI clock frequency.

Best regards,
Mayank Shadwani

Mayank Shadwani said:

but I need to confirm whether the SDK example is also configured to use the external clock source (like your custom bootloader) or if it's configured differently. Can you please capture the same oscilloscope screenshot at the same probe point when running the SDK SBL example? This will help us verify that both the SDK and your custom code are using the same clock source configuration. If the SDK is using a different clock source or if the waveform looks different, that would explain the discrepancy.

While running the SDK SBL example project, I probed the same test point and observed the same waveform on the oscilloscope.

How can I confirm which external clock source the SDK is using as the reference clock? Could you point me to the register name or the logic in the SDK SBL code (C file name) that configures it?

I checked the register TOP_RCM_TOP_RCM_PLL_REF_CLK_SRC_SEL, and its value is 0x00000000, which indicates that the on-die clock is selected as the PLL reference clock. This register value is the same in both the SDK SBL example and my custom boot project.

As you mentioned earlier

Mayank Shadwani said:

TOP_RCM_PLL_CORE_STATUS bit 6 is showing 1'b0, which indicates PLL_CORE_STATUS_LOSSREF (Reference input loss).

In the SDK SBL project, the value of TOP_RCM_TOP_RCM_PLL_CORE_STATUS is 0xC0001E10, but in the custom boot project it is 0xC0001E12.
In both cases, bit-6 is 1'b0, which indicates PLL_CORE_STATUS_LOSSREF.

I need some help in understanding where the PLL configuration is done in the SDK sbl_ospi_multicore_elf example.
Could you point me to the source file or the API responsible for PLL configuration, so that I can review and compare the configuration sequence with my custom boot project?

Mayank Shadwani  can u look into it

Mayank Shadwani  can you look into this

Hi,
check the following path for PLL configuration APIs: sdk_path/source/drivers/soc/{device}/soc.c and soc_rcm.c

Regards,
Shivank