OMAP L137 Ethernet problem

There is no evidence to suggest that the 3 port switch is the nature of your problem and your comment is unwarranted and doesn't really instil people working on this product to want to help you. Many others have succesfully used ethernet on this product.

Lets try to keep the conversation civil and on the problem at hand here :)

Ken Dougherty said:

But I cannot get anything to go out the wire - specifically how do I associate a channel in the MAC with a specific PHY address?

This may be a better question for the switch manufacturer than TI, there may be some configuration  you could do over MDIO to manage this process, however I am not all that familiar with the Micrel switch being used (KSZ8893MQL), I suspect as it appears to be a standard switch the data would come out one PHY or the other depending on the packet's destination by default, if this was manually controlled anywhere it would be in the switch not in the EMAC on the L137. It claims to be a managed switch so I suspect you can configure it in such a fashion so as to be a direct connection to a single PHY.

Ken Dougherty said:

(Who was the !@#$!@#$!@#$ that thought it would be a good idea to put a 3 port switch on here anyway?)

The switch is there on the EVM because one of the target applications is VOIP, having the switch means you can have the board setup like a IP phone, where Ethernet essentially passes through the board (if you have a VOIP phone in your office it probably has two Ethernet jacks as well), essentially it is there to act as sort of a reference design.

I received our first prototype (uses Micrel KSZ8041NL for a PHY) - reconfigured PINMUX registers and the code came up without a hitch.

hi

i have an evm omap l137 and i have some problam with emac-loopback example, when i run it i recieve 4 or 5 error.(I mean in the text that it print) i cant send or recieve data. please let me know why and what should i do now?

I don't know - I never got the network to work on my EVM at all...  Getting the EVM was a bust (for me - your mileage may vary).

But - In general... when posting questions like this it would be a good idea to post the error messages that you are seeing...

After including those, add the following code to the beginning of your nic init function.

i have this example but i don't understand where should i add these codes!(nic init function)

Hello all,

I have the same problem with emac-loopback example .

is there any help?

Mazaheri.

I only learned recently that the SDI-provided EVM emac_loopback test requires an ethernet loopback plug in order to work.

-Tommy

Hi Tommy,

I used an ethernet loopback jack and the example worked .

Thanks,

Zahra.

Dear Ken:

I use the OMAPL137 & KSZ8041NL also and I'm struggling the loopback example, could you please show me what PINMUX you set so I can check if there is something wrong for my configuration? Or below is my configuration and may you take time to check it?

Thank you.

"txtPINMUX19"="0x00000001"
"txtPINMUX18"="0x88111812"
"txtPINMUX17"="0x28222222"
"txtPINMUX16"="0x22222222"
"txtPINMUX15"="0x22444444"
"txtPINMUX14"="0x44222222"
"txtPINMUX13"="0x22882228"
"txtPINMUX12"="0x18112128"
"txtPINMUX11"="0x22281122"
"txtPINMUX10"="0x22222228"
"txtPINMUX9"="0x82282812"
"txtPINMUX8"="0x28822111"
"txtPINMUX7"="0x11111111"
"txtPINMUX6"="0x11111111"
"txtPINMUX5"="0x11111111"
"txtPINMUX4"="0x11111111"
"txtPINMUX3"="0x11111111"
"txtPINMUX2"="0x11111111"
"txtPINMUX1"="0x11111111"
"txtPINMUX0"="0x11112188"

Calvin,

Your PINMUX looks good to me (I only looked at registers 9 and 10   9 should be xx2xxxxx and 10 should be 2222222x - which you have.

I'm using a L138 and the RMII interface...  (L138 and L:137 have very different pinmux layout)

    Also - make sure that sysclk7 is at 50mhz... (Scope it if you can - I did!)

    Also - I have the RESET line for the KSZ8041NL wired to a GPIO point so I can get at it from software.

             (I do not take it out of reset until the clocks are stable and the code initialized)

Here  is a dump of my current L138 syscfg registers - and some code snippets below from where I set the relevant bits

     (Yes, I really do type in code that looks like that.... basically the TI documentation PDF file reformatted as C)

    (Our code base predates TI buying Code Composer (Back in the prehistoric 'C25 and 'C33 DSPs) so no DSP/BOIS no CSL, etc.)

SYSCFG_REVID       0x01c14000.... 0x4e840102 Revision Identification     

SYSCFG_DIEIDR0     0x01c14008.... 0x0701d017 Die Identification 0        
SYSCFG_DIEIDR1     0x01c1400c.... 0x0056166a Die Identification 1        
SYSCFG_DIEIDR2     0x01c14010.... 0x00000080 Die Identification 2        
SYSCFG_DIEIDR3     0x01c14014.... 0x37f20002 Die Identification 3        
SYSCFG_DEVIDR0     0x01c14018.... 0x1b7d102f Device Identification 0     
SYSCFG_DEVIDR1     0x01c1401c.... 0x00000000 Device Identification 1     
SYSCFG_BOOTCFG     0x01c14020.... 0x00000002 Boot Configuration          
SYSCFG_CHIPREVIDR  0x01c14024.... 0x00000032 Chip Revision               
SYSCFG_KICK0R      0x01c14038.... 0x00000000 Kick 0                      
SYSCFG_KICK1R      0x01c1403c.... 0x00000000 Kick 1                      
SYSCFG_HOST0CFG    0x01c14040.... 0x00000001 Host 0 Configuration        
SYSCFG_HOST1CFG    0x01c14044.... 0x00800001 Host 1 Configuration        
SYSCFG_IRAWSTAT    0x01c140e0.... 0x00000000 Interrupt Raw Status/Set    
SYSCFG_IENSTAT     0x01c140e4.... 0x00000000 Interrupt Enable Status/Clear
SYSCFG_IENSET      0x01c140e8.... 0x00000000 Interrupt Enable            
SYSCFG_IENCLR      0x01c140ec.... 0x00000000 Interrupt Enable Clear      
SYSCFG_EOI         0x01c140f0.... 0x00000000 End of Interrupt            
SYSCFG_FLTADDRR    0x01c140f4.... 0x00000000 Fault Address               
SYSCFG_FLTSTAT     0x01c140f8.... 0x00000000 Fault Status                
SYSCFG_MSTPRI0     0x01c14110.... 0x44442222 Master Priority 0           
SYSCFG_MSTPRI1     0x01c14114.... 0x44440000 Master Priority 1           
SYSCFG_MSTPRI2     0x01c14118.... 0x54604404 Master Priority 2           
SYSCFG_PINMUX0     0x01c14120.... 0x80000000 Pin Multiplexing Control 0  
SYSCFG_PINMUX1     0x01c14124.... 0x88888888 Pin Multiplexing Control 1  
SYSCFG_PINMUX2     0x01c14128.... 0x44444400 Pin Multiplexing Control 2  
SYSCFG_PINMUX3     0x01c1412c.... 0x44444444 Pin Multiplexing Control 3  
SYSCFG_PINMUX4     0x01c14130.... 0x88442288 Pin Multiplexing Control 4  
SYSCFG_PINMUX5     0x01c14134.... 0x11888888 Pin Multiplexing Control 5  
SYSCFG_PINMUX6     0x01c14138.... 0x14111111 Pin Multiplexing Control 6  
SYSCFG_PINMUX7     0x01c1413c.... 0x11111111 Pin Multiplexing Control 7  
SYSCFG_PINMUX8     0x01c14140.... 0x11111111 Pin Multiplexing Control 8  
SYSCFG_PINMUX9     0x01c14144.... 0x11111111 Pin Multiplexing Control 9  
SYSCFG_PINMUX10    0x01c14148.... 0x11111118 Pin Multiplexing Control 10 
SYSCFG_PINMUX11    0x01c1414c.... 0x11111111 Pin Multiplexing Control 11 
SYSCFG_PINMUX12    0x01c14150.... 0x11111111 Pin Multiplexing Control 12 
SYSCFG_PINMUX13    0x01c14154.... 0x88888880 Pin Multiplexing Control 13 
SYSCFG_PINMUX14    0x01c14158.... 0x88888880 Pin Multiplexing Control 14  RMII interface (ethernet)L138
SYSCFG_PINMUX15    0x01c1415c.... 0x00000088 Pin Multiplexing Control 15  RMII interface (ethernet)L138

SYSCFG_PINMUX16    0x01c14160.... 0x00000000 Pin Multiplexing Control 16 
SYSCFG_PINMUX17    0x01c14164.... 0x00000000 Pin Multiplexing Control 17 
SYSCFG_PINMUX18    0x01c14168.... 0x11021200 Pin Multiplexing Control 18 
SYSCFG_PINMUX19    0x01c1416c.... 0x10000000 Pin Multiplexing Control 19 
SYSCFG_SUSPSRC     0x01c14170.... 0xffffffff Suspend Source              
SYSCFG_CHIPSIG     0x01c14174.... 0x00000000 Chip Signal                 
SYSCFG_CHIPSIG_CLR 0x01c14178.... 0x00000000 Chip Signal Clear           
SYSCFG_CFGCHIP0    0x01c1417c.... 0x00000000 Chip Configuration 0        
SYSCFG_CFGCHIP1    0x01c14180.... 0x00000000 Chip Configuration 1        
SYSCFG_CFGCHIP2    0x01c14184.... 0x00008602 Chip Configuration 2        
SYSCFG_CFGCHIP3    0x01c14188.... 0x0000ff05 Chip Configuration 3        
SYSCFG_CFGCHIP4    0x01c1418c.... 0x0000ff00 Chip Configuration 4        

Snippets from my code... (L138 based)

   SYSCFG_PINMUX14 = 0         // Pin    | as used            0             1                 2           4             8           
                  | (8 << 28)  //  W17   | RMII_RXER       PRU0_R31[24]  VPIF_DIN2         UHPI_HD[10]  UPP_D10       RMII_RXER      
                  | (8 << 24)  //  V17   | RMII_RXD[0]     PRU0_R31[25]  VPIF_DIN3         UHPI_HD[11]  UPP_D11       RMII_RXD[0]    
                  | (8 << 20)  //  W16   | RMII_RXD[1]     PRU0_R31[26]  VPIF_DIN4         UHPI_HD[12]  UPP_D12       RMII_RXD[1]    
                  | (8 << 16)  //  R14   | RMII_TXEN       PRU0_R31[27]  VPIF_DIN5         UHPI_HD[13]  UPP_D13       RMII_TXEN      
                  | (8 << 12)  //  V16   | RMII_TXD[0]     PRU0_R31[28]  VPIF_DIN6         UHPI_HD[14]  UPP_D14       RMII_TXD[0]    
                  | (8 <<  8)  //  U18   | RMII_TXD[1]     PRU0_R31[29]  VPIF_DIN7         UHPI_HD[15]  UPP_D15       RMII_TXD[1]    
                  | (8 <<  4)  //**V15*  | <unused>        PRU1_R31[16]  VPIF_CLKIN1       UHPI_HDS1    PRU1_R30[9]   GP6[6]         
                  | (0 <<  0); //**W14*  | <unused>        UPP_2xTXCLK   VPIF_CLKIN0       UHPI_HCS     PRU1_R30[10]  GP6[7]         
                                                                                                                                    
   SYSCFG_PINMUX15 = 0         // Pin    |                                                                                          
                  | (0 << 28)  //**R19   | <unused>        PRU0_R31[10]  VPIF_DIN10        UHPI_HD[2]   UPP_D2        PRU0_R30[10]   
                  | (0 << 24)  //**R18   | <unused>        PRU0_R31[11]  VPIF_DIN11        UHPI_HD[3]   UPP_D3        PRU0_R30[11]   
                  | (0 << 20)  //**T16   | <unused>        PRU0_R31[12]  VPIF_DIN12        UHPI_HD[4]   UPP_D4        PRU0_R30[12]   
                  | (0 << 16)  //**U19   | <unused>        PRU0_R31[13]  VPIF_DIN13_FIELD  UHPI_HD[5]   UPP_D5        PRU0_R30[13]   
                  | (0 << 12)  //**V19   | <unused>        PRU0_R31[14]  VPIF_DIN14_HSYNC  UHPI_HD[6]   UPP_D6        PRU0_R30[14]   
                  | (0 <<  8)  //**V18   | <unused>        PRU0_R31[15]  VPIF_DIN15_VSYNC  UHPI_HD[7]   UPP_D7        PRU0_R30[15]   
                  | (8 <<  4)  //  W19   | RMII_CRS_DV     PRU1_R31[29]  VPIF_DIN0         UHPI_HD[8]   UPP_D8        RMII_CRS_DV    
                  | (8 <<  0); //  W18   | RMII_MHZ_50_CLK PRU0_R31[23]  VPIF_DIN1         UHPI_HD[9]   UPP_D9        RMII_MHZ_50_CLK

// CHIP CONFIG 3 Register: EMIFA clock select/RMII/PLL1/PRUEvt
   SYSCFG_CFGCHIP3   = 0                                  
      | ( 0    << 16)      //  31-16 reserved
      | (0x7F  <<  9)      //  15- 9 reserved MUST be 0x7F
      | ( 1    <<  8)      //      8 0=MII mode   1==RMII mode
      | ( 0    <<  7)      //      7 reserved
      | ( 0    <<  6)      //      6 UPP_TX_CLKSRC (0=ASYNC3, 1=2xTXCLK)
      | ( 0    <<  5)      //      5 PLL1_MASTER_LOCK Register Lock (0 = freely accessable, 1=locked)
      | ( 0    <<  4)      //      4 ASYNC3_CLKSRC  (0=PLL0_SYSCLK2, 1=PLL1_SYSCLK2)
      | ( 0    <<  3)      //      3 PRUEVTSEL (0=normal mode, 1=alternate mode)
      | ( 1    <<  2)      //      2 Enable DIV4p5 (0=disabled, 1=enabled)
      | ( 0    <<  1)      //      1 EMIFA (ALTERA) 0->uses SYSCLK3   1->uses DIV4p5
      | ( 0    <<  0);     //      0 reserved

Dear Ken:

   Thanks for kindly help.

   I checked from scope and find clock distorted due to both omapl137 and external clock generator have sent  out 50 M Hz clock.

   After remove external clock generator, if PINMUX9[23:20] set as "0010", I can see 50M Hz clock output on the pin "RMII_MHZ_50_CLK". If PINMUX9[23:20] set as "0000",  no clock output found on the scope. It seems when configure as "0010", OMAPL137 will generate 50M Hz clock to pin "RMII_MHZ_50_CLK" then feed into EMAC sub-system.

   The data sheet  "Figure 6-5. EMAC clocking diagram" in "6.3.4 EMAC clocking" of SPRUG84 (September 2008) mybe wrong and give opposite option. From the figure, I will think when configuring as "0000", EMAC sub-system will use internal system clock, when configure as "0010", it will accept external clock, maybe it's my misunderstanding.

   However after handling the clock violation, the example still failed to work properly. The packet received equal to transmitted but data verification failed. It seems not  "ethernet loopback plug" problem, I'm still checking ...