- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Also, that "Frame dropped" meesage occurs while I'm not sending it anything.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 :(.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page