AM5716：cpsw rgmii0 : rx crc err

user5170864

Part Number: AM5716
Other Parts Discussed in Thread: AM5726,

I use am57xx & TI‘s dp83822.

83822 connect to cpsw port with rgmii.

sdk 4.0.3

There is no rx rcr err when I don"t use the net transport datas very fast.But,when I trans dats with full speed ,there‘s a lot of rx crc errs .

1 I found ：It will be affected by the initialization configuration of related pins in uboot。When I set the receive pin to pull up, the error rate can reach 10%. Set high resistance (5%) to pull-down (3.8). I don't know what to configure pins according to. (the configuration of phy ID will also be affected when pin configuration is modified.)

2 2. I found that the iodelay configuration is provided in uboot. When I use the configuration corresponding to am5716, there are many CRC errors. I modify the configuration in the am5716 manual (table 7-85. Manual functions mapping for GMAC rgmii0). However, when I use the configuration of am5726, the CRC error will be greatly reduced, which can reach 2%. I want to know whether I should continue to modify this configuration and what parameters in this configuration are calculated based on

over 5 years ago

0 Vishal Mahaveer over 5 years ago

TI__Mastermind 33320 points

Hi,

You have to use the correct IODELAY values for RGMII pins. For IODELAY configuration values, take the latest from data sheet of the device.
AM5716 data sheet -- https://www.ti.com/lit/ds/symlink/am5716.pdf

The values you are showing here does not match the data sheet. Can you try the correct values from the data sheet and test?

Regards,
Vishal

0 user5170864 over 5 years ago in reply to Vishal Mahaveer

Prodigy 40 points

I've tried the parameter configuration in the link, and the result is worse. In the case of a small amount of data communication, the CRC error is more than 10%. The parameter configuration with 572x is only 1.5%, and it is in the state of full speed transmission.

0 Vishal Mahaveer over 5 years ago in reply to user5170864

TI__Mastermind 33320 points

Hi,

When you updated the IODELAY values, you also have MANUAL_MODE enabled in the padconfig of RGMII lines right?

Regards,
Vishal

0 user5170864 over 5 years ago in reply to Vishal Mahaveer

Prodigy 40 points

Yes, I enabled "manual mode" during the test. Otherwise, the test results should not change when I modify the parameters of iodelay. I also tested that "manual mode" was turned off, and the results were much better than those using 5716's parameters, which was close to the test results with 5726 parameters.

0 Vishal Mahaveer over 5 years ago in reply to user5170864

TI__Mastermind 33320 points

Hi,

Could you check the behavior by updating below register to disable the internal delay?

Register - 0x4A002534 (CTRL_CORE_SMA_SW_1)
Bit - 25 (RGMII1_ID_MODE_N)

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/rgmii_5F00_id_5F00_mode.png

Regards,
Vishal

0 user5170864 over 5 years ago in reply to Vishal Mahaveer

Prodigy 40 points

Hello, I did what you said. The internal delay is turned off by configuring in uboot. The CRC error rate is twice the test result when using 572x configuration.

0 Vishal Mahaveer over 5 years ago in reply to user5170864

TI__Mastermind 33320 points

Hi,

The IODELAY values in the datasheet should guarantee the timings in the datasheet. We think the issue is due to two sides not configured to use compatible internal delay mode.

You should perform a timing analysis using the timing values from both the AM57x and the DP83822, and using the programmed Internal Delay Modes.

Regards,
Vishal

0 Lin_Charles over 5 years ago in reply to Vishal Mahaveer

TI__Expert 4260 points

Hi Vishal,

It is nice to know you here. I have some questions about your response here,

1. Using the timing values from both the AM57x and the DP83822, you mean we should set the AM571x time value to meet DP83822 timing requirements? Could you please help show us what value we should meet in DP83822?

2. How we get values in the register? For example (0x06F0, 413, 0), how we get 413 and 0 here? Thanks.

BR,

Charles Lin

0 Vishal Mahaveer over 5 years ago in reply to Lin_Charles

TI__Mastermind 33320 points

Hi Charles Lin,

For #1, you can try posting the query on https://e2e.ti.com/support/interface/f/138

For #2, these IODELAY values are mentioned in the datasheet and these values guarantee the timings in the datasheet.

Regards,
Vishal

0 Lin_Charles over 5 years ago in reply to Vishal Mahaveer

TI__Expert 4260 points

Hi Vishal,

Thank you for your response here. I think our IO delay target can use the below value, 1-2ns. Could you please help provide how to calculate the RXCTL_IN clock delay to get 1-2ns in AM5716? Thanks.

BR.

Charles Lin

0 Lin_Charles over 5 years ago in reply to Vishal Mahaveer

TI__Expert 4260 points

Hi Vishal,

Thank you for your response here. I think our IO delay target can use the below value, 1-2ns. Could you please help provide how to calculate the RXCTL_IN clock delay to get 1-2ns in AM5716? Thanks.

BR.

Charles Lin

0 kcastille over 4 years ago in reply to Lin_Charles

TI__Guru 54282 points

Charles,

Refer to the DP838222 data sheet table titled "0x0017 RMII and Status Register".

Can you double check the state of the "RGMII RX Clock Shift" register? This should be set to 1 to properly center the clock and data coming from the PHY.

Regards,

Kyle

Processors

Processors forum

AM5716：cpsw rgmii0 : rx crc err