Getting LinkStatus by emac_pool() in 6657

Hi Kazunori,

I apologize for the delay in replying to this. The emac_poll function, and most of the MDIO-related functions, are ported from the previous c64x. The actual parts on the chip and registers should be the same, but something may have been missed during the porting.

Instead of calling the emac_poll function, can you try writing a custom one that just looks at the values of the MDIOLink and MDIOLinkIntRaw? See if those values matches the physical state of the connection.

Let me know your status. I will get an EVMC6657 to work on this issue and continue tracking your progress on this thread.

-Ivan

Hi, Ivan.
Thank you for your reply.

I checked the MDIO registers.
In user task I read MDIO LINK and LINKINTRAW in 100msec interval.

Result:
 - LINK some times reads "0" although cable is connected.
 - LINKINTRAW always reads "0"

I suspect another driver clears LINKINTRAW, ( ex. MDIO_timerTick() )
so I set hardware watch point at LINKINTRAW and LINKINTMASKED for WRITE.
but I can't find where writes the register.

-------
This is the log.
 I disconnect cable ONCE (middle of this log).
 There is no record that indicates LINKINTRAW reads not 0.

[C66xx_0] Up Count  :487  LINK : 0x00000000
[C66xx_0] Down Count:1  LINK : 0x01000000
[C66xx_0] Up Count  :4  LINK : 0x00000000
[C66xx_0] Down Count:1  LINK : 0x01000000
[C66xx_0] Up Count  :14  LINK : 0x00000000
[C66xx_0] Down Count:1  LINK : 0x01000000
[C66xx_0] Up Count  :3  LINK : 0x00000000
[C66xx_0] Down Count:1  LINK : 0x01000000
[C66xx_0] Up Count  :100  LINK : 0x00000000
[C66xx_0] Down Count:1  LINK : 0x01000000
[C66xx_0] Up Count  :156  LINK : 0x00000000
[C66xx_0] Down Count:1  LINK : 0x01000000
[C66xx_0] Up Count  :50  LINK : 0x00000000
[C66xx_0] Down Count:1  LINK : 0x01000000
[C66xx_0] Up Count  :8  LINK : 0x00000000
[C66xx_0] Down Count:1  LINK : 0x01000000
[C66xx_0] Up Count  :120  LINK : 0x00000000  --  To here . Host Receives reply of ping every time(NO TIMEOUT).
[C66xx_0] Down Count:35  LINK : 0x01000000  <--- I pull ether cable here. and re-connect.
[C66xx_0] Up Count  :110  LINK : 0x00000000  --- From here Host dosn't receive reply of ping.(ALL TIMEOUT)
[C66xx_0] Down Count:1  LINK : 0x01000000
[C66xx_0] Up Count  :20  LINK : 0x00000000
[C66xx_0] Down Count:1  LINK : 0x01000000
[C66xx_0] Up Count  :49  LINK : 0x00000000
[C66xx_0] Down Count:1  LINK : 0x01000000
[C66xx_0] Up Count  :53  LINK : 0x00000000
[C66xx_0] Down Count:1  LINK : 0x01000000
[C66xx_0] Up Count  :6  LINK : 0x00000000
[C66xx_0] Down Count:1  LINK : 0x01000000

This is source code of usertask

for(;;){  
   static int last_link = 0;
   static int down_cnt = 0;
   static int up_cnt = 0;
   int link;
   link =MDIO_REGS->LINK;
   if(!link) down_cnt++; else up_cnt++;
   if(last_link != link){
    /* if link changes , print down/up count*/
    if(link){/* Down -> Up */
     platform_write("Down Count:%d  ",down_cnt);
     down_cnt=0;
    } else { /* Up -> Down */
     platform_write("Up Count  :%d  ",up_cnt);
     up_cnt=0;
    }
    platform_write("LINK : 0x%08x\n", link);
    last_link = link;
   }
   link =MDIO_REGS->LINKINTRAW;
   if(link)
    platform_write("LININTRAW : %08x\n", link);

  TaskSleep(100);
}

Thank you.
- Kazunori.

Kazunori,

LINKINTRAW might not be written anywhere in the code, but updated by the MDIO peripheral instead. I can see the error after disconnecting the cable. I'll update when I can get a better idea of what is happening.

Sorry again for the delay.

-Ivan

Hi, Ivan.

I found following code have emac re-establish connection, after disconnect and re-connect cable.
Next I want to know is , Why MDIO_REGS->LINK sometimes reads "0" although cable is connected.
Or another way to know linkstatus, trigger for writing GMII_EN bit.
Thank you.

----------------

 for(;;) {
   static int last_link = 0;
   static int down_cnt = 0;
   static int up_cnt = 0;
   int link;
   link =MDIO_REGS->LINK;
   if(link) up_cnt++; else down_cnt++;
   if(last_link != link){
    /* if link changes , print down/up count*/
    if(link){/* Down -> Up */
     platform_write("Down->Up  Down Count:%d  ",down_cnt);
     /* toggle GMII Enable */
     Emac_osalEnterSingleCoreCriticalSection(0);
     EMAC_REGS->MACCONTROL &= ~0x00000020;
     EMAC_REGS->MACCONTROL |= 0x00000020;
     Emac_osalExitSingleCoreCriticalSection(0);
     down_cnt=0;
    } else { /* Up -> Down */
     platform_write("Up -> Down  Up Count  :%d  ",up_cnt);
     up_cnt=0;
    }
    last_link = link;
   }
  TaskSleep(100);
  }

Kazunori,

I'm sorry it's taking me longer than expected to get a clear answer. I am also seeing what you are seeing, and forcing the GMII to reset seems to restart the connection. One of the abnormalities I'm seeing is that the MDIOAlive (0x02C08808) and MDIOLink (0x02C0880C) registers have changing values regardless of the Ethernet cable plugged in or not. I saw this by opening up the memory browser in CCS and turning on continuous refresh. MDIOLinkIntRaw (0x02C08810) also remains 0, indicating link was never changed.

I don't have a clear answer yet, but I will be raising this question to a colleague who knows more about the EMAC hardware and see if he can pitch in on why this is happening. In the meantime, I will also see if I can match the link status directly on the Marvell PHY.

-Ivan

Kazunori,

An update on this: We are still discussing internally on why the MDIO status bits are flickering.

I saw your other post about the Ethernet cable disconnecting and reconnecting on the C6000 Multicore forum. If you are using our NIMU driver with NDK, you can implement the EmacPoll function in nimu_eth.c, for example:

static void EmacPoll (NETIF_DEVICE* ptr_net_device, uint timer_tick)
{
*((Uint32 *)(0x02c08160)) &= ~0x00000020;
*((Uint32 *)(0x02c08160)) |= 0x00000020;
return;

}

This is by no means elegant and meant to be a workaround. In this scenario, EmacPoll will be called periodically to toggle the GMII_EN bit, as you suggested in your previous post. I will update again when I have more news about the hardware link status in MDIO.

-Ivan

Ivan

Thank you for corresponding.

I 've tryed your workaruond.
It causes about 30% loss of receive performance , to resetting MDIO every EmacPoll.
Now, I'm seeing bit 0 of SGMII_REGS->STATUS. (0x02c08914)

It seems to be stable than PHY LinkStatus.
I know experientially that SGMII LinkStatus bit downs longer than about 1 second after it is once down by cable is pulled,
So I think We never miss rising edge of link status. But I am worried about missing it.

So, I 'm worried about resetting every time or triggered by SGMII link status.

I wll wait for news about PHY link status.

regards.
- Kazunori.

Hi Ivan.

resetting GMII every EmacPoll has probrem.
Resetting when receiving frame, MAC receiveer acts strange.

So I need the accurate trigger for resetting GMII.

===
I sending large amount of incrimental data from host to DSP by TCP.

Fist of all,  Log outputs as following.

[C66xx_0] 00366.804 NIMUReceivePacket: Bad Size; Payload is 2891 bytes <- about 2000~3000
[C66xx_0] 00366.804 NIMUReceivePacket: Bad Size; Payload is 0 bytes

Next, EMAC  Rx Ch0 Completion Descriptor shows following, when dsp receive a long frame .

it shows 2 Ether frames are joined.
frame buffer is as following.

Top of the first buffer

Tail of the first buffer

Top of the second buffer
 

tail of the second buffer

In a Image,

Regards,
-Kazunori.

Hi,

this is my latest code in [nimu_eth.c].
---- static int last_link = 0; /* I have only one ether port so this works   */

static void EmacPoll (NETIF_DEVICE* ptr_net_device, uint timer_tick)
{
 static int last_link = 0;
 int link;
 //link =MDIO_REGS->LINK;
 link =*((Uint32 *)(0x02c08914)) & 0x0001;    /*SGMII Status*/
 if(last_link != link){
  if(link){/* Down -> Up */
   *((volatile Uint32 *)(0x02c08160)) &= ~0x00000020;
   *((volatile Uint32 *)(0x02c08160)) |=  0x00000020;
  }
  last_link = link;
 }
 return;

}

Hi Kazunori,

Just to make sure we are aligned, are you working on our TI EVM or are you working on a custom board?

-Ivan

Hi, Ivan.

I 'm working on EVM6657LE.
Big endian mode.
And I don't use AMC's SGMII port. AMC is NOT connected.

Kazunori.

Kazunori,

Can you provide a measurement of the MDC clock frequency?  It can be measured on pins 3 and 6 of U244.  This is the MDC/MDIO level translator to go from 1.8V to 2.5V for the PHY.  We want to be sure the software is setting this up correctly.  It is on the backside of the board above the DSP close to the edge of the board.  It has clear silkscreen labeling.

Tom

Hi Tom.

Frequency is both 1.00MHz.

MDIO_CONTROL register(0x02c08804) is 0x410000A5

Pin3(DSP_MDC) is quite clear square wave form.
But pin6(ETH_MDC) is rounded. like following.

-Kazunori.

Kazunori,

Were you expecting a frequency of 1.00MHz?  What is your Main PLL clock frequency?  You can verify it by measuring the signal at the SYSCLKOUT testpoint after enabling this output in the DEVSTAT register.

Why did you attach a sketch of the waveform?  Can you attach an actual scope capture showing the clocks?

Tom

1) yes i measured 1.00MHz
   The time between rising edge to rising edge is 1 usec.
   This is wavefrom observed at pin6
  
2) SYSCLKOUT(TP12)
  160-170MHz(I think it is 166Mhz, so PLL is set to 1GHz)
  this is one at TP12.

3) waveform.
 the reason I've attached my drawing was I just thought you are worried about bandwidth of the level converter.
 I have only poor instruments, It was easier drawing scketch
 than take rich one from the other division. 
 If you need more shap ones , tell me pls.

Regards
 

Kazunori,

Can you reprogram the Main PLL to a lower rate between 800 and 900MHz and then measure the frequency at both SYSCLKOUT and MDC?

Tom

Hi, Tom.

MainPLL : 800MHz
SYSCLKOUT : 133MHz
MDC : 800KHz

MainPLL : 900MHz
SYSCLKOUT : 150MHz
MDC ; 900KHz

-Kazunori.

0800MHz SCLK

800MHz MDC

900MHz SCLK


900MHz MDC

Kazunori,

Thanks for these captures.  Can you use the MDIO interface to repeatedly read a static register in the PHY that has a known value?  We would like to see whether you are gettting errored reads.  If you read a bad value, can you attach a scope to the MDC and MDIO and provide a capture of the bus when the invalid data is returned.

Tom

Hi, Ti.

Tom,
Thanks a lot for helping me as your best in scope of your business.
But, I can't take more permission by our company to debugging EVM whitch is a product of eInfochips and TI.
My job is only to evaluate C6657's performance for our future products.
So, I appologize not to seeing MDIO communication.
(I beleave we've reached next to the solution.)

now,I change my questions.

1. Will TI investigate into this phenomenon as a known issue?
2. And when do you indicate me confirmed solution or workaround or update?

Sincerely,
-Kazunori.

Kazunori,

Thanks for your help.  We will continue to look into this issue.  I expect it will take a week or two to resolve.

Tom

Kazunori,

Can you supply the model number and serial number for your C6657 EVM?  This will help us isolate the problem.

Tom

Hi, Tom.

Thanks , I'll wait for news.
Beta 2-TI v2.0-092

-Kazunori.

Are there any updates?

Hi, Tom.
Thank you for your investigation.
I can inform our hardware desgin division, for desigining our custom board.

Finally , I'm going to have a job-change , end of this month.
So, I can't try your suggestion that changeng registers.

-Sincerely,
Kazunori.