Nios® II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
12366 Discussions

Simple Socket Server not responding

Altera_Forum
Honored Contributor I
827 Views

Hi, All, 

I'm a newbie in FPGA and embedded designs (and new to this forum as well). 

 

My system has a NIOS-II, TSE MAC, ETX PHY and external SSRAM. 

I've reached a point where the Simple Socket Server app is running 

on the board, and 'listening' on port 30. However, I can't get it to 

respond: all Telnet connection attempts, PINGs, etc. are not working. 

 

Any ideas?  

 

Thanks, 

Ran.
0 Kudos
10 Replies
Altera_Forum
Honored Contributor I
80 Views

Did You search the forum?

Altera_Forum
Honored Contributor I
80 Views

Hi, Socrates- Thanks for the quick reply. You're right- I didn't search the 

forums. I'll do that and update here. 

Ran
Altera_Forum
Honored Contributor I
80 Views

Hi, 

Well, after going through all the relevant messages, no help. 

 

The TSE MAC receives correct Ethernet frames: I can see that from the  

statistics registers of the MAC (no errors, all frames are valid). 

 

How can check what's wrong from this point onwards? Any ideas? 

 

Thanks, 

Ran
Altera_Forum
Honored Contributor I
80 Views

I'd say 99% bad or no timing constraints.

Altera_Forum
Honored Contributor I
80 Views

If the statistics registers on the MAC are increasing then it could be something else than timing. Here are a few things I suggest:[list][*]is the board using an IP address other than 0.0.0.0? Either use a fixed address, or check that it gets a correct one from DHCP. It should print it in the terminal.[*]Use an Ethernet sniffer on the PC you are connecting to the board (Wireshark is a good one) and check that at least the ARP request that the PC sends gets an answer from the board[*]use signaltap probes on the tx and rx stream interfaces between the TSE and the DMAs, and compare the contents with the packets shown in Wireshark.[/list]

Altera_Forum
Honored Contributor I
80 Views

I had same problems and it was timing. All the reception paths were perfectly fine, but the transmit part had failing paths because of MII/GMII buses mux. That damn thing needs long paths...

Altera_Forum
Honored Contributor I
80 Views

Oh interesting.... Each time I had timing problems it was on the receive side. Good to know!

Altera_Forum
Honored Contributor I
80 Views

Hi, Daixien, Socrates, 

 

-I'm using a static IP, as given in the example: 198.162.1.233, or something similar. The gateway is also 198.162.1.1 

 

-Wireshark sees no incoming packets from the board, at all. 

 

-I'm trying to watch the stream interface with signaltap, but I see nothing: 

either my trigger is off (what should it be? the _write signal or the irq maybe?) 

or there is really no traffic on it, which might be the issue. 

 

If so, what can cause the stream interface to not work?  

 

I should point out that if i'm using the debugger, I can see the software reacting to incoming packets in the background. I just can't figure out 

what it see that causes it to ignore them... 

 

Thanks, 

Ran
Altera_Forum
Honored Contributor I
80 Views

You should synchronize with the sop (start of packet) signal. You can also add the valid and ready signals as triggers. 

Can you dump the received packets contents (either from the software side, or in signaltap) and compare with what Wireshark says? If you are seeing software activity then it means something is received.
Altera_Forum
Honored Contributor I
80 Views

Hi, Guys, 

I wanted to update you all that I found the problem: 

The connection between the SGDMAs and memory was wrong. 

 

I'm using an external SRAM which is not supported by the default controllers shipped with Qsys, so I created my own using the Tri-State Controller. 

I have 4 external chips, so I have 4 TS controllers, all of them 

connected to the NIOS. 

 

The SGDMAs of the Ethernet MAC should also be connected to the memory, of course: but I connected them to Controller 0, and for some reason the software was trying to R/W to Controller 1. I discovered this when I checked (using SignalTap) the actual addresses the SGDMA were trying to reach each time a Ping is received.  

 

Anyway, I changed the memory connection to Cont. 1, and everything work.  

Thanks to all those who gave advices, have a great day :-) 

Ran
Reply