RM57L843: VCLKA4, VCLKA4_DIVR, and the EMAC

Christian Bauer

Part Number: RM57L843
Other Parts Discussed in Thread: DP83620, HALCOGEN

Greetings!

We are using the RM57L843 in a design that makes use of its Ethernet controller. The EMAC is connected via MII to a PHY (DP83620) which runs on its own 25 MHz crystal.

The RM57L843 datasheet (SPNS215C), section 6.6.3, states that this requires VCLKA4_DIVR_EMAC to be 25 MHz, so I set up PLL2 to 100 MHz and configure VCLKACON1 to select PLL2 as the source for VCLKA4, with a divider VCLKA4R = 3 for VCLKA4_DIVR. With this configuration, the EMAC runs perfectly fine, sending and receiving Ethernet packets in a stress test for days in a row.

To verify the clocking, we have used the Clock Test feature to route VCLKA4 and VCLKA4_DIVR to the external outputs. We are measuring 100 MHz for VCLKA4 (SEL_GIO_PIN = 1110) as expected, but also 100 MHz for VCLKA4_DIVR (SEL_ECP_PIN = 01110) which looks wrong. However, the "EMAC clock output" setting for SEL_ECP_PIN), which does not seem to be explained any further in the documentation, gives the expected 25 MHz clock.

To investigate the discrepancy of the VCLKA4_DIVR measurement, I've changed the VCLKA4R divider to 7, which still gives 100 MHz for VCLKA4_DIVR but the expected 12.5 MHz for the "EMAC clock output". The EMAC still works perfectly fine with this setting. With other divider values, the "EMAC clock output" changes accordingly, so this clock test signal is obviously not related to the PHY clock. Still, VCLKA4_DIVR looks wrong.

Next, I changed the VCLKA4 clock source to the LF LPO and leave the divider at 7. Now I get 78 kHz for VCLKA4_DIVR on the clock test, and 9.7 kHz for the "EMAC clock output". Surprisingly, the EMAC still works fine.

So maybe VCLKA4(_DIVR) isn't actually needed for the EMAC (as suggested by a comment on Figure 6-6 of the datasheet)? To check this, I set VCLKA4_DIV_CDDIS in VCLKACON1. Now the "EMAC clock output" disappears, and the EMAC stops working. Similarly, when I disable the entire VCLKA4 clock domain via VCLKA4_OFF in the CDDIS register, I now measure 0 for both VCLKA4_DIVR and the "EMAC clock output" and the EMAC doesn't work.

So, apparently the EMAC requires some internal clock but has a very large tolerance regarding the frequency (10 kHz..100 MHz).

Questions:
- Why is it that, with the original settings, we measure 100 MHz for both VCLKA4 and VCLKA4_DIVR, instead of the expected 25 MHz for VCLKA4_DIVR?
- What does the "EMAC clock output" option of the Clock Test feature route to the external pin?
- What is the actual requirement for the frequency of VCLKA4/VCLKA4_DIVR to use an externally clocked PHY via MII?

Regards,
Christian

over 2 years ago

0 jagadish gundavarapu over 2 years ago

TI__Guru 69701 points

Hi Christian,

I started working on your issues and will try to provide an update ASAP.

Thanks & regards,
Jagadish.

0 jagadish gundavarapu over 2 years ago in reply to jagadish gundavarapu

TI__Guru 69701 points

Hi Christian,

My apologies for the late replay.

Christian Bauer said:
To verify the clocking, we have used the Clock Test feature to route VCLKA4 and VCLKA4_DIVR to the external outputs. We are measuring 100 MHz for VCLKA4 (SEL_GIO_PIN = 1110) as expected, but also 100 MHz for VCLKA4_DIVR (SEL_ECP_PIN = 01110) which looks wrong. However, the "EMAC clock output" setting for SEL_ECP_PIN), which does not seem to be explained any further in the documentation, gives the expected 25 MHz clock.

To investigate the discrepancy of the VCLKA4_DIVR measurement, I've changed the VCLKA4R divider to 7, which still gives 100 MHz for VCLKA4_DIVR but the expected 12.5 MHz for the "EMAC clock output". The EMAC still works perfectly fine with this setting. With other divider values, the "EMAC clock output" changes accordingly, so this clock test signal is obviously not related to the PHY clock. Still, VCLKA4_DIVR looks wrong.

Can you please create a sample project with above mentioned issues, so that i can easily debug and update you.

Thanks & regards,
Jagadish.

0 Dieter Dornberger1 over 2 years ago in reply to jagadish gundavarapu

Prodigy 160 points

as a supplement to my colleague's questions

Unfortunately, we can't pass on our project, but the problem can be reproduced very easily with CCS in debug mode.
This is our GCM HalCoGen Setup in our test environment:
VCLKA4 Src: PLL2 100 MHz
VCLKA4_DIV 12.5 MHz
VCLA4_S 100 MHz

The EMAC still works perfectly fine with this setting, although VCLKA4_DIV = 12.5 MHz, why ?

Changing in the Memory Browser Register 0xFFFFFF8C (CLKTEST) to 0x0005000E,
according to the TRM SPNU562A table 2-50 we expect the clock VCLKA4_DIVR with 12.5 MHz

But at ECLK1 output (Ball A12) we measured 100 MHz and not 12.5 MHz, why ?

Changing in the Memory Browser Register 0xFFFFFF8C (CLKTEST) to 0x00050017,
according to the TRM SPNU562A table 2-50 we expect the clock EMAC clock output, source of this clock signal ?

At ECLK1 output (Ball A12) we measured 12.5 Mhz

Next test only to verify a correct setting of the CLKTEST register:
Changing in the Memory Browser Register 0xFFFFFF8C (CLKTEST) to 0x00050014,
according to the TRM SPNU562A table 2-50 we expect the clock VCLK3 with 37.5 MHz.

At ECLK1 output (Ball A12) we measured 37.5 Mhz, OK

Changing GCM in HalCoGen setup (our standard setup):
VCLKA4 Src: PLL2 100 MHz
VCLKA4_DIV 25 MHz
VCLA4_S 100 MHz

The EMAC still works perfectly fine with this setting.
Changing in the Memory Browser Register 0xFFFFFF8C (CLKTEST) to 0x0005000E,
according to the TRM SPNU562A table 2-50 we expect the clock VCLKA4_DIVR with 25 MHz.
But at ECLK1 output (Ball A12) we measured 100 MHz and not 25 MHz, why ?
Changing in the Memory Browser Register 0xFFFFFF8C (CLKTEST) to 0x00050017,
according to the TRM SPNU562A table 2-50 we expect the clock EMAC clock output.
At ECLK1 output (Ball A12) we measured 25 Mhz.

Anaother changing GCM in HalCoGen setup:
VCLKA4 Src: VCLK 75 MHz
VCLKA4_DIV 37.5 MHz
VCLA4_S 75 MHz

The EMAC still works also perfectly fine with this setting,
Changing in the Memory Browser Register 0xFFFFFF8C (CLKTEST) to 0x0005000E,
according to the TRM SPNU562A table 2-50 we expect the clock VCLKA4_DIVR with 37.5 MHz.
But at ECLK1 output (Ball A12) we measured 75 MHz and not 37.5 MHz, why ?
Changing in the Memory Browser Register 0xFFFFFF8C (CLKTEST) to 0x00050017,
according to the TRM SPNU562A table 2-50 we expect the clock EMAC clock output.
At ECLK1 output (Ball A12) we measured 37.5 Mhz.

Best regards,

Dieter

0 jagadish gundavarapu over 2 years ago in reply to Dieter Dornberger1

TI__Guru 69701 points

Hi Dieter,

Thanks for the detailed steps.

I will try to reproduce the issue now and will update you soon.

Thanks & regards,
Jagadish.

0 jagadish gundavarapu over 2 years ago in reply to jagadish gundavarapu

TI__Guru 69701 points

Hi Dieter,

Apologies for the delay, i was overloaded so passing the thread to my colleague. He is an expert in Hercules devices.

Thanks & regards,
Jagadish.

+1 QJ Wang over 2 years ago in reply to jagadish gundavarapu

TI__Guru**** 196206 points

Hello,

The purpose of providing this "VCLKA4_DIVR" or "EMAC clock output" is to avoid having a second clock source on the PCB for the Ethernet PHY. You can generate the required 25MHz or 50MHz clock signal on "VCLKA4_DIVR" or "EMAC_CLK_Output" and send it to the PHY via the ECLK1 pin. If PHY is clocked using EMAC_CLK_Output, the MII_TX_AVCLK4 and MII_RX_AVCLK4 functionality should be selected from I/O pinmux.

EMAC_CLK_Output = VCLKA4 / VCLKA4R

The "EMAC_Clock_Output" was added on RM57Lx device and routed to ECLK1 pin, the "VCLKA4" replacing VCLK4_DIVR was connected to ECLK1 (SEL_ECP_PIN=01110.)

0 Christian Bauer over 1 year ago in reply to QJ Wang

Prodigy 30 points

Hi,

Thanks for the explanation of the clocks! I think that explains our measurement results.

Regards,
Christian

Arm-based microcontrollers

Arm-based microcontrollers forum

RM57L843: VCLKA4, VCLKA4_DIVR, and the EMAC