TMS320C6678: C6678 occasionally cannot communicate with ethernet

I'm looking into this. Feedback will be posted here.

Best Regards,
Yordan

Hi,

Which sdk version are you running?

In general
0x8000008 means:
bit 31 is set => 1 = The MAC is in the idle state => MAC does not process anything.
bit 3 is set => External Fullduplex. This is the value of the EXT_FULLDUPLEX input bit => Fullduplex mode is enabled.

In the case when you CANNOT ping your board, you have Fulduplex mode enabled and MAC is busy (active state):
Bit 31 is 0 =The MAC is not in the idle state.

I you're running your custom bare metal example, can you post your project?

Best Regards,
Yordan

Thank you for your reply.

Sorry, our projects can not be posted.
SDK version is "processor_sdk_rtos_c667x_3_01_00_06".

I confirmed that the MAC_status value changed after BIOS_start() was called.
I am using SYS/BIOS 6.45.1.29.

Are there any similar reports?


fukuda.

Hi,

I've notified the sw team. Their feedback will be posted here.

Best Regards,
Yordan

Hi,

"NC_NETSTART" =====> do you use a NDK package for this? What version of this? Do you run the example NIMU_emacClientExample_EVMC6678C66BiosExampleProject or how your example looks like? You used PHY, so the SGMII of C6678 is set to slave mode with auto-negotiation on? 1Gbps full dulpex?

Regards, Eric

Hi,

I use ndk2.24.03.35 for this project.

I haven't confirmed with that example though,
in my project, When I'm trying to connect MAC to MAC
DSP is in MasterMode.
and It's also 100M full duprex and auto-negotiation on.

Is that correct way?

My custom board is made up of DSP, 88e1111.
DSP connects to 88e1111 with SGMII,
whose signal is converted to RGMII signal using RGMII bridge mode.
Then, it connects to Ethernet switch IC.

Best regards

Hi,

It looks DSP uses 100 Mb duplex and master mode, it should be OK if you have the link come up. Do you see any MDIO ALIVE and LINK register changes in working and failure case?

The EVM we have here is SGMII port connected to PHY with 1Gbps slave mode + auto-negotiation. After I power on the card, the MAC_STATUS is 0. Then there is a GEL file to initialize the SGMII and serdes, the MAC_STATUS changes to 0x8100_0018. Mac is already idle.

Regards, Eric

Hi.

So far, I haven't solved this problem.

In both cases of working and failure,
the MDIO_ALIVE register and the MDIO_LINK register indicate no error:
the values returned by CSL_MDIO_isPhyAlive(phyAddr) and CSL_MDIO_isPhyLinked(phyAddr) are 1.

I also checked and read the MDIO registers directly, (ALIVE: 0x02090308, LINK: 0x0209030C)
and confirmed that not only MDIO but also SGMII_Status and 88E1111_register do not change in both case.

I do not understand why MAC_STATUS will be fixed to BUSY and what makes it BUSY.
So I doubt various factors.

An example I am wondering is,
in the NDK content /nettools/config/config.c,
_CfgEntryProcess () does not return because "returncode = pc->pCbService[pe->Tag-1]( pc, pe->Tag, pe->Item, op, pe );" line dosen't complete.
Dose it work correctly or not?

Regards.

Hi,

Before you running any code, what is the MAC_STATUS? It is busy or not?

"I found something new about the problem.

When NC_NETSTART function calls NetIPAddr,

the Value of MAC_STATUS is always changed to 0x00000008 at top of NetIPAddr."

Do you mean NC_NETSTART---->NS_BootTask---->CfgSetService(), which of the callback didn't return? How the MAC_STATUS related to function return or no return?

Regards, Eric

Hi.

if the callbacks are not related, it's OK, thanks.

By the way, MAC_STATUS value seems to be 0x80000008 (not busy) before NC_NetStart.
I found that nimu seems to be a cause to change MAC_STATUS.
After NIMU_qmssQPush (gPaTxQHnd[8], pCppiDesc, dataBufferSize, SIZE_HOST_DESC, Qmss_Location_TAIL); in Emacsend of nimu called,
the status changed to 0x8 and it remains 0x8 after that. This is when I face the problem.

I think Cppi_setPSFlags evaluates something,then it changes MAC_STATUS to busy, but I don't understand.
According to the comment above qmssQPush,

/* Send the packet out the mac. It will loop back to PA if the mac/switch

* have been configured properly
*/

I understand that if I had MAC setting wrong, I couldn't communicate Ethernet.
But it happens only sometimes.

What parameter is related? What do you think that make it happen?
Could you help me?

Best Regards

Hi,

I was able to resolve this issue.

I made the following changes in Init_MAC() of nimu_eth.c.
As I mentioned in the previous post, it is 100M / Fullduplex setting.

CSL_CPGMAC_SL_enableFullDuplex (macPortNum);
CSL_CPGMAC_SL_enableGMII (macPortNum);
//CSL_CPGMAC_SL_enableGigabit (macPortNum);
CSL_CPGMAC_SL_disableGigabit (macPortNum);
//CSL_CPGMAC_SL_enableExtControl (macPortNum);
CSL_CPGMAC_SL_disableExtControl (macPortNum);

I have some questions.

In the initial setting of SGMII,
the ADV_ABILITY register and registers related to SGMII are done correctly,
and autonegotiation is also completed successfully.

In the MAC_STATUS register,
"EXT_GIG" bit indicates 0 and "EXT_FD" bit indicates 1
in both failure case and working case.
(This shows the state of FULLDUPLEX_IN and GIG_IN, dosen't it?)

All of the following commands returned TRUE in original setting,
not only in normal state but also in abnormal state.
So I'm sure that these were set correctly.

CSL_CPGMAC_SL_isExtControlEnabled()
CSL_CPGMAC_SL_isFullDuplexEnabled()
CSL_CPGMAC_SL_isGigabitEnabled()

Although ExtControl is enabled,
I think MAC doesn't work with EXT_GIG and EXT_FD.

Is this a MAC external control bug, and
how can I check what mode MAC works with?

The code of initialization of SGMII is shown below.

CSL_SGMII_startRxTxSoftReset (macPortNum);
// CSL_SGMII_disableMasterMode (macPortNum);
CSL_SGMII_enableMasterMode (macPortNum);
CSL_SGMII_enableAutoNegotiation (macPortNum);
CSL_SGMII_endRxTxSoftReset (macPortNum);

/* Setup the Advertised Ability register for this port:
* (1) Enable Full duplex mode
* (2) Enable Auto Negotiation
* (3) Enable the Link
*/
sgmiiCfg.linkSpeed = CSL_SGMII_100_MBPS;
sgmiiCfg.duplexMode = CSL_SGMII_FULL_DUPLEX;
sgmiiCfg.bLinkUp = 1;
CSL_SGMII_setAdvAbility (macPortNum, &sgmiiCfg);

do
{
CSL_SGMII_getStatus(macPortNum, &sgmiiStatus);
if (waitcnt++ > 10000000) {
platform_write("SGMII is not linked up!!!!\n");
platform_write("Halt Start Up\n");
while(1);
}
} while (sgmiiStatus.bIsLinkUp != 1);

/* Wait for SGMII Autonegotiation to complete without error */
do
{
CSL_SGMII_getStatus(macPortNum, &sgmiiStatus);
if (sgmiiStatus.bIsAutoNegError != 0)
return; /* This is an error condition */
} while (sgmiiStatus.bIsAutoNegComplete != 1);

I think it is similar to the following post.
e2e.ti.com/.../168148

Regards.

Hi,

Glad to know the issue was resolved by setting:
disable gigabit mode and disable ext_en. Those are MAC_CONTROL registers.

After the code change, what is the MAC_CONTROL register bit 7 (GIG) and bit 18 (EXT_EN)? Are they both zero? What is bit 0 (FULLDUPLEX), is it 1?

Then, below functions just read the MAC_CONTROL bit, how they can all true?
CSL_CPGMAC_SL_isExtControlEnabled()
CSL_CPGMAC_SL_isFullDuplexEnabled()
CSL_CPGMAC_SL_isGigabitEnabled()

Regards, Eric

Hi,

We implemented those commands to read the set values using the CSL functions,
then We directly read the values from the pointer address.
We confirmed that bit 18 (EXT_EN) and bit 7 (GIG) have changed,
and bit 0 (FULLDUPLEX) remains zero.

before(working):
 mac0:FULL DUPLEX
 mac0:GMII enable
 mac0:GIGABIT enable
 mac0:ExtControl enable
 mac0:RxCSF enable
 mac1:FULL DUPLEX
 mac1:GMII enable
 mac1:GIGABIT enable
 mac1:ExtControl enable
 mac1:RxCSF enable
 MAC0control reg-read:add= 2090904 , value= 8400a1
 MAC0status reg-read:add= 2090908 , value= 80000000
 MAC1control reg-read:add= 2090944 , value= 8400a1
 MAC1status reg-read:add= 2090948 , value= 80000008

before(failure):
 mac0:FULL DUPLEX
 mac0:GMII enable
 mac0:GIGABIT enable
 mac0:ExtControl enable
 mac0:RxCSF enable
 mac1:FULL DUPLEX
 mac1:GMII enable
 mac1:GIGABIT enable
 mac1:ExtControl enable
 mac1:RxCSF enable
 MAC0control reg-read:add= 2090904 , value= 8400a1
 MAC0status reg-read:add= 2090908 , value= 80000000
 MAC1control reg-read:add= 2090944 , value= 8400a1
 MAC1status reg-read:add= 2090948 , value= 8

after:
 mac0:FULL DUPLEX
 mac0:GMII enable
 mac0:GIGABIT disable. 10/100M enable
 mac0:ExtControl disable
 mac0:RxCSF enable
 mac1:FULL DUPLEX
 mac1:GMII enable
 mac1:GIGABIT disable. 10/100M enable
 mac1:ExtControl disable
 mac1:RxCSF enable
 MAC0control reg-read:add= 2090904 , value= 800021
 MAC0status reg-read:add= 2090908 , value= 80000000
 MAC1control reg-read:add= 2090944 , value= 800021
 MAC1status reg-read:add= 2090948 , value= 80000008

In addition, we also found the following two alternative solutions.

1)

CSL_CPGMAC_SL_enableFullDuplex (macPortNum);
CSL_CPGMAC_SL_enableGMII (macPortNum);
//CSL_CPGMAC_SL_enableGigabit (macPortNum);
CSL_CPGMAC_SL_disableGigabit (macPortNum);
CSL_CPGMAC_SL_enableExtControl (macPortNum);

2)

CSL_CPGMAC_SL_enableExtControl (macPortNum);///first enableExtCtrl
CSL_CPGMAC_SL_enableFullDuplex (macPortNum);
CSL_CPGMAC_SL_enableGMII (macPortNum);
CSL_CPGMAC_SL_enableGigabit (macPortNum);
//CSL_CPGMAC_SL_enableExtControl (macPortNum);

In both case, the MAC_CONTROL register was set to the desired value,

and no network failure occurred at more than 100 restart checks.

Considering the case of 2,
first setting ExtControl and then setting FullDuplex and Gigabit afterwards.
Therefore, for enableExtControl, it should be set to 10/100M , and it should not make Gigabit enabled.

However, in the default case,
first setting Duplex and Gigabit and then setting ExtControl afterwards,
As a result, the external signal setting is 10/100M, but it has gigabit settings for a moment.

I think that this may sometimes cause network problems.

Do you think this is a problem?
If the configuration is not gigabit,
does not it depend on the ExtControll setting value?
and does it need to set the 10/100M setting with the disableGigabit function?

Regards.

Hi,

I found another solution.

It is to run CSL_CPGMAC_SL_enableGMII() at the end of following commands.

CSL_CPGMAC_SL_enableFullDuplex (macPortNum);
//CSL_CPGMAC_SL_enableGMII (macPortNum);
CSL_CPGMAC_SL_enableGigabit (macPortNum);
CSL_CPGMAC_SL_enableExtControl (macPortNum);
CSL_CPGMAC_SL_enableGMII (macPortNum); 　

According to the explanation of GMII_EN in the MAC_CONTROL register,

0 indicates the reset state of "GMII receive and transmit", 1 indicates that its reset release state.

I think that reset should be released after each settings.

In addition, when MAC_STATUS is stuck in "busy state",

I found that it was necessary to set GMII_EN disabled temporarily, then set it enabled in order to fix this.

MAC_STSATUS indicates "idle_state" and works correctlly in this case.

Therefore, I think the reason why the MAC enters the busy state is abnormality of "GMII receive and transmit".

I think that it is best to set GMII_EN at the end of the init sequence.

What do you think?

Regards.

Hi,

Sorry for the late response! You mentioned that this is TI SGMII to 88E1111 SGMII connection and TI SGMII is the master with auto-negotiation.

In our driver code, we are using SGMII connected to PHY for EVM, where PHY is the master, TI SGMII is the slave with auto-nego.  We have init_sgmii() called first, then init_mac(). You showed several ways to resolve this problem in init_mac() function. I am not sure if you did init_sgmii() modification correctly or not, please check TI KeyStone Architecture Gigabit Ethernet (GbE) Switch Subsystem UG 2.4.3. If you set TI SGMII as the master, I assume you set it to 100Mbps with fullduplex, I don't know the reason you have to set the EXT_EN to let a stable connection. Please see 2.4.3.3.1, "In the MAC module, the user can optionally set the EXT_EN bit in the MAC_CONTROL Register to allow the speed and duplex mode to be set by the signals from the SGMII." Can you double check if TI SGMII is the master by looking at SGMII_CONTROL and MR_ADV_ABILITY registers?

Regards, Eric

Hi,

I understand that the setting of the EXT_EN bit is optional.
However, EXT_EN is ON for the provided driver.
I think that you are turning on EXT_EN for versatility, but it may not work correctly.

Considering from some of the codes I showed,I think that abnormality may occur when operation mode switched by external control and after reset is released by GMII_EN.
Even if the external control is on, when the operation mode switching does not occur, it does not become abnormal.

According to your advice, the conclusion of this issue,modified the MAC driver as "EXT_EN is OFF, 100 Mbps and fullduplex setting".
I also confirmed that "TI SGMII" was set as the master in both cases before and after the modification.

I'm wondering about following points.
Does this mean that the PDK library code needs to be modified directly by the user?
Does it mean that the PDK library may not be used without modification?

Regards