Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12599 Discussions

Simple Socket Server not responding

Altera_Forum
Honored Contributor II
1,116 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 II
369 Views

Did You search the forum?

0 Kudos
Altera_Forum
Honored Contributor II
369 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
0 Kudos
Altera_Forum
Honored Contributor II
369 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
0 Kudos
Altera_Forum
Honored Contributor II
369 Views

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

0 Kudos
Altera_Forum
Honored Contributor II
369 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]

0 Kudos
Altera_Forum
Honored Contributor II
369 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...

0 Kudos
Altera_Forum
Honored Contributor II
369 Views

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

0 Kudos
Altera_Forum
Honored Contributor II
369 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
0 Kudos
Altera_Forum
Honored Contributor II
369 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.
0 Kudos
Altera_Forum
Honored Contributor II
369 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
0 Kudos
Reply