Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
21615 Discussions

OpenCores MAC driver error mesages

Altera_Forum
Honored Contributor II
3,820 Views

Hello! 

 

Im using a custom board with a KS8721BT chip. It have not any initialization so in the eth_ocm_phy_init() function i'm reseting it and waiting for auto negoriation to complete. 

 

Apparently everything it's ok, I have the following log in the program: 

=============== Software License Reminder ================ 

This software project uses an unlicensed version of the NicheStack TCP/IP 

Network Stack - Nios II Edition. If you want to ship resulting object 

code in your product, you must purchase a license for this software from 

Altera. For information go to: "http://www.altera.com/nichestack

===================================================== 

InterNiche Portable TCP/IP, v3.1  

 

Copyright 1996-2008 by InterNiche Technologies. All rights reserved.  

eth_ocm_prep 

Your Ethernet MAC address is 2a:52:61:75:6c:2a 

Static IP Address is 192.168.1.18 

prepped 1 interface, initializing... 

[eth_ocm_init] 

[eth_ocm_phy_init] PHY ID 0x1f 22 1619 

[eth_ocm_phy_init] Found KS8721B/BT PHY 

[eth_ocm_phy_init] KS8721B/BT Auto-neg capabilities: 0x1e1 

[eth_ocm_phy_init] LXT972A not found! 

[eth_ocm_phy_init] Marvell 88E1111 PHY not found! 

[eth_ocm_phy_init] DP83848C PHY not found! 

[eth_ocm_phy_init] Waiting on PHY link...OK. x=11164, PHY STATUS=786d 

[eth_ocm_phy_init] Full Duplex is 1 

[eth_ocm_init] Configuring MAC address 2a:52:61:75:6c:2a 

 

Opencores MAC post-init: MODER = 0x0000a403 

mctest init called 

IP address of et1 : 192.168.1.18 

Created "Inet main" task (Prio: 2) 

Created "clock tick" task (Prio: 3) 

 

Simple Socket Server starting up 

[sss_task] Simple Socket Server listening on port 30 

Created "simple socket server" task (Prio: 4) 

 

But after a moment I have the next messages: 

Frame dropped: too busy to receive 

Frame dropped: too busy to receive 

Frame dropped: too busy to receive 

Frame dropped: too busy to receive 

Frame dropped: too busy to receive 

...(for ever!) 

 

Any idea why this happen? I'm using a static IP, no DHCP enable in the Niche Stack.
0 Kudos
12 Replies
Altera_Forum
Honored Contributor II
1,055 Views

Also, that "Frame dropped" meesage occurs while I'm not sending it anything.

0 Kudos
Altera_Forum
Honored Contributor II
1,055 Views

Hah! I wrote it, you'd think I might know what the problem is. Let me go look at the driver and see if I can refresh my memory. 

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
1,055 Views

Okay the message is printed on line 575 of "ins_eth_ocm.c".  

 

//Check for busy flag if(result & ETH_OCM_INT_MASK_BUSY_MSK){ # if (ETH_OCM_DBG_LVL >= 3) dprintf("Frame dropped: too busy to receive\n"); # endif dev->info->netp->n_mib->ifInDiscards++; } 

 

So if everything is working properly and if memory serves me correctly, the MAC should only set that BUSY_MSK flag if a packet comes in and the receive FIFO is full. The MAC then discards the packet and sets the error bit in the descriptor. 

 

So we need to find out why this is happening. 

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
1,055 Views

Correction, it doesn't set the error bit in the descriptor, it's just an interrupt to the processor. 

 

Here is the associated Verilog: 

//Set Busy IRQ if a new frame comes in and //we're too busy to receive it. always @(posedge rxclk) rx_bsy <= rx_sop & rx_dv & ~rx_rdy; 

 

In other words, if a new packet comes in and the Receive FIFO is full, you will get this error. 

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
1,055 Views

Hello! 

Well vthank you so much for your answer, but i don't know exactly why this is happening neither. I'm just compiling the simple socket server with the default options.  

The wear think it's this: the program worked... at the begining. But 

but could only send 72 bytes(I reduced the startup menu to just "Hello Nios II telnet test\n") and the leds where turning On and Off.  

 

It worked a few times... and then suddenly it stop working... since tuesday this is not reponding to anything. I've tried all, rebuilding the project, recompiling... 

 

I've tried the following: 

- I activated the following macros: 

NPDEBUG, NAIVE_PRINTF and ETH_OCM_DBG_LVL=10. 

- In SOPC: TX buffers are now 4096(128 was the default). I thought this  

could be a reason why it could only send 72 bytes. 

- In the PHY initialization function I'm NOW restaring the chip. While the  

example was working i didn't make any initialziation sequence since the  

chip datasheet says nothing about it. I'm also waiting for the  

autonegotiation to complete. 

 

My board have the KS8721BT chip, no flash, (MAC and IP are hardcoded, no DHCP enable). Why the buffers would be filled? I'm not sending anything to it :(.
0 Kudos
Altera_Forum
Honored Contributor II
1,055 Views

oh and men, if you have any documentation about how your driver works I would like to read it, I would like to find out the problem myself without causing discomfort. 

 

And thank you!
0 Kudos
Altera_Forum
Honored Contributor II
1,055 Views

Documentation ... yes that would be nice. Unfortunately all that exists is what is found in the accompanying Word document which is pretty minimal.  

 

Obvious things to check: 

 

1 - Have you constrained the timing for the PHY? 

2 - Are you meeting timing requirements on all clock domains? 

3 - Can you view the packets on the network (via Wireshark or some other packet sniffer)? 

4 - What speed and duplex are you running in? 

5 - What version of the MAC are you using? 

6 - What version of the tools are you using? 

 

BTW - You should be able to bump the TX fifo back down. The larger fifo really won't help much. 

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
1,055 Views

O'right, i've tested with all that: 

 

1.- There are some warning in the compilation but are related to the pll. I've been always receiving this warnings, even with the sram memories but they always worked. I'm sure the PHY connection it's OK... well at least I can read the registers in the chip(PHYID and other for initialziation) and make a basic config, I can read them, check for autonegotiation completition. When there is no ethernet cable connected autonegotiation never ends... which is the expected behavior. 

2.- The OpenCores MAC doesn't come with a sdc file(at least i`ve not found it) 

3.- That's even wearer... I can't see even my request :S. I've checked the switch and it's not filtering anything. Also as I told you the program worked fine at the begining(except for the 72 bytes stuff...) 

4.- 100Mbps full duplex, this is correctly detected by the chip 

5.- 8.03 

6.- Quartus and Nios Building tools for eclipse 9.1. I've changed the attribute 'AFFECTS_PORT_WIDTHS' in the _hw.tcl by AFFECTS_ELABORATION(this is the new name for 9.0+)... but again, the MAC worked at the begining without this change. 

 

Oh men... i'll have to do what I didn't want to: understand your driver. Well any link about the ideas used wil be apreciated. 

 

Bye! and thx again!
0 Kudos
Altera_Forum
Honored Contributor II
1,055 Views

1 - Warnings concern me. Regardless though, you need to constrain the TX and RX interfaces between the FPGA and the PHY. These interfaces run at both 25MHz and 2.5MHz. In contstraining these interfaces, you'll need to constrain the clocks and data lines. You'll need to take into account the tsu, th, and tco timing parameters given for your PHY. You should ideally also take board trace length and skew into account but you may choose to ignore these if they are negligible. 

Your ability to communicate with the PHY via the MDIO interface has no impact on the TX and RX interfaces. If there is a hardware problem with regards to the error you are receiving, it's either in the RX clock domain or in your system clock domain. BTW, how fast is your system clock? 

 

2 - You are correct, I haven't provided the an SDC file. 

 

I am completely willing to explain the driver in depth to you. However, that is not the first place to look with regards to your problem. There is no point debugging the software until you are certain the hardware is rock solid. 

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
1,055 Views

Men you are right. When I sended more than 7 byets a packet was genrated, wut the data was corrupted. My sniffer(wirshark) show me something like this: 

"Se==rver===socket!34", all the bytes appeared.. but with garbage in the middle. I'll have to assign constrraints to my desogn. I've never used the scriptt tools, now I'll have to learn... 

 

Oh and my system it's runing the CPU at 100 MHZ, OCMAC and memory at 60MHz. I'll try reducing this speeds and/or using just one. Is there any macro related to the clock speed?
0 Kudos
Altera_Forum
Honored Contributor II
1,055 Views

Oh right men, I'll add the constraints(I've never used the script interface before). 

My system has a processor at 100MHz(f variation), OCM and memory at 60MHz.
0 Kudos
Altera_Forum
Honored Contributor II
1,055 Views

Hello jakob! 

Well I'm sorry for not replying before and have forgotten this thread. We didn't notice the compilation was reporting some critical timing warnings (...). That's what what we are working on right now. 

Thx for your help.
0 Kudos
Reply