AM2432: AM2432 MII interface TXC/Data delay setting do not work.

Tao Han said:

Now they want delay data signal ~20 us. 

20us? This setting only allows ns range tweaks. Why do they need to delay this ?

Hi Pratheesh:

Sorry it is typo. Customer want to delay about 20ns. set 0x103xxxxx, enable the bit 30-28 bit to 0x1 but from hardware wave probe. 

Data vs clock do not has any delay. Could you please check whether those modify is right?

Best Regards!

Han Tao

Hi Pratheesh:

In order to change MII interface clock/data delay. Except we  delay about 2 second after PRU firmware start up. Does we miss though thing to make it work? 

Please share some suggest and we can try it.

Best Regards!

Han Tao

Can you try a higher value like 6 or 7 and see whether this is taking effect. Also for testing purposes, you can always update this from memory browser if you have access to DUT via JTAG.

Hi Pratheesh:

Has changed bit30-28 to 0x6. but probe the PRG1_PRU0 ball do not delay. Below is the pin V9/pin AA8 capture wave. clock falling edge and data just 1.19999us delay.

Does we directly writer 0x300B2010 method is not right? 

Best Regards!

Han Tao

Hi Experts:

As you suggest that we try changing MII_RT_TXCFG1 register instead? Reason is due to Port swap in MII mode. _TXCFG1 controls PHY0 delay and _TXCFG0 controls PHY1 delay.

Looks like change 0x30032012 register bit 30-28 value to 0x01 and 0x06 test ball pin V9 PRG1_PRU0_GPO16 and ball pin AA8 PRG1_PRU0_GPO11. The MII clock/data do not add 20ns delay. Below are the capture wave.

Could you please check except change TXCFG1/TXCFG0 whether has another register need modified?

Best Regards!

0x30032012 bit 30-28 =0x1

0x30032012 bit 30-28 =0x6

Hi experts:

This is 0x30032012 value. FYI

Han Tao

Hi Tao,

Just to clarify, is the customer using ICSSG1 instance or ICSSG0 instance? From the conversations above, ICSSG1 (0x300B2012) is being used. Is there any specific reason why 0x30032012 (ICSSG0 offset) is modified?

The customer will have to try changing 0x300B2014 (MII_RT_TXCFG1):

Regards,
Aaron

Hi Aaron:

Please check this problem history.

1. Customer change 0x300B2012 at 19/Jan, the wave post at this ticket beginning.

2. Last week Pratheesh told us that AM24x is Port swap. TXCFG1 control PHY0 delay we change 0x30032012 again. You can see that capture wave several minutes ago.

So 0x30032012/0x300B2012 customer tried, it will not affect MII clock/data delay.

Best Regards!
Han Tao

Apologies for the confusion in my previous reply.

Tao Han said:

2. Last week Pratheesh told us that AM24x is Port swap. TXCFG1 control PHY0 delay we change 0x30032012 again. You can see that capture wave several minutes ago.

0x30032000 to 0x3003206C is the location for ICSSG0 PRU_MII_RT_MII_RT Registers.

In your case, the setup is using ICSSG1 instance, for which the corresponding registers are from 0x300B2000 to 0x300B206C.

So, as per the previous suggestion, in order to change MII_RT_TXCFG1 of ICSSG1 instance, the customer will have to modify 0x300B2014.bit30-28.

HI Aaron:

Thanks for your suggest. But customer modified 0x300B2014 bit 30-28 to 0x1 and 0x6. They feedback that probe MII clock/data the wave do not change. Customer has tried modify 0x30032010 and 0x30032014 bit 30-28, all those two register do not affect MII clock/data delay at their board.

Does we has more suggest about it?

Best Regards!

Han Tao

Hi Aaron:

Sorry it is typo. We modify 0x300B2010 and 0x300B2014 at customer board. Probe the signal MII clock/data do not delayed.

Best Regards!

Han Tao

Hi Tao,

Thank you for the update. I will try to do the same activity from our side and understand the behavior. Please expect an update by Friday.

Regards,
Aaron

Hi Aaron:

Thanks for help us verify it at your side. Waiting for your good new about it.

Best Regards!

Han Tao

Hi Tao,

I tested the following topology:

TwinCAT <> ET2000 <> AM243x-LP (SubDevice)

I modified 0x300B2017 (bit28-30) Register to 0x01, 0x02 and 0x03.

The observation is that at values 0x01 and 0x02, the TwinCAT reports lost frame continously until the TX_CLK_DELAY0 is reverted back to 0. At 0x03, the SubDevice goes into INIT_ERR state.

Do note that I used logic analyzer (saleae) to probe the TX_CLK, TXD0, TXD1, TXD2 and TXD3 of PHY0 (ICSSG1 Port0) but the delay wasn't visible much. I will have to use an oscilloscope to check for the presence of the delay in the TX data line.

My follow-up question is that is the customer seeing this MainDevice behavior (Lost frame and INIT_ERR) when updating the corresponding TX_CLK_DELAY0 ?

Regards,
Aaron

Hi Aaron:

Appreciate help us verify those wave at EVM board. From your result maybe those 0x300B2017 just affect AM64/AM24x internal delay, do not change hardware waveform level delay.

Because this register customer feedback that they just can 0x300B2017 before load ind_comms_sdk_am243x_2025_00_00_08 PRU firmware, the register value will be changed by PRU firmware. They just can change it through JTAG. So the lost frame rate at YT8522 whether change 0x300B2017 to 0x1 or 0x6 they can not confirm it. 

Below two pictures are the register change at customer code. FYI

Best Regards!

Han Tao

Hi Tao,

Tao Han said:

Because this register customer feedback that they just can 0x300B2017 before load ind_comms_sdk_am243x_2025_00_00_08 PRU firmware, the register value will be changed by PRU firmware.

If 0x300B2017 is modified before PRU firmware is loaded, then the firmware will over-write it with the default value.

Tao Han said:

They just can change it through JTAG. So the lost frame rate at YT8522 whether change 0x300B2017 to 0x1 or 0x6 they can not confirm it. 

Can I get details on the topology you are testing for the TX_CLK_DELAY impact, more specifically, the MainDevice used? Updating 0x300B2017 through JTAG after PRU should be good enough for understanding and debugging the impact. 

Regards,
Aaron

Hi Aaron:

Customer test method is same as you. The maindevice use PC. below is their test environment setup:

TwinCAT <-> YT8522+AM2432BSEFHIALVR                

It is ethernet cable direct connect PC and AM24 production.  Then power on/off AM2432 production board, some time PC will report the frame error and it will continue report it. 

Need power off AM2432 then power on again, it probability setup the stable Ethercat connect with TwinCAT again.

Best Regards!

Han Tao

Hi Tao,

Tao Han said:

It is ethernet cable direct connect PC and AM24 production.  Then power on/off AM2432 production board, some time PC will report the frame error and it will continue report it. 

Couple of follow-up questions:

• Is this issue observed with TX_CLK_DELAY0 set to a non-zero value?
• Can you also share the wireshark log when this frame error is observed?
• Can you confirm once if the application is loaded correctly after the first power on and off?
• Which SDK example is the customer using?
• Please share the ESC Error registers as well: 
  • 

Regards,
Aaron

Hi Han,

So I was able to successfully program TX_CLK_DELAY1 with the above mentioned topology and following is my observation:

• TX_CLK_DELAY1 = 0x1
  •  
  • The observation is that a delay of 4-6ns is seen with respect to TX_CLK

• TX_CLK_DELAY1 = 0x2
  • 
  • The observation is that a delay of 8-10ns is seen with respect to TX_CLK

• TX_CLK_DELAY1 = 0x3
  • 
  • The observation is that a delay of 12-14ns is seen with respect to TX_CLK

Do note that the above tests are done by modifying the register from the Memory Browser available in the CCS workspace. I will also try similar by modifying it from the EtherCAT driver as well to see if it is getting overwritten by the firmware during firmware initialization.

Regards,
Aaron 

Hi Aaron:

Thanks for help us verify it at EVM board. We will follow your same method test it again at customer side.

Best Regards!
Han Tao

hi Aaron:

Confirmed with customer. They change those register can get same results like you.

When AM24x board start up and after PRU firmware start run. Software change those register the packet loss will disappear.

Customer will continue optimize their software with us and this case we can close it.

Best Regards!

Han Tao