Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Honored Contributor I
1,068 Views

SimpleSocketServer (EP3C120 DB)

I have been working with the CycloneIII Development board (EP3C120) using QuartusII 9.1sp2 with the project daixiwen (http://alteraforums.com/forum/member.php?u=4443) linked at: 

http://alteraforums.com/forum/showthread.php?p=90831#post90831 

 

I created the NIOS template project Simple Socket Server and am having problems with connecting to the server through telnet. The only modification required to compile was Enabling the NicheStack component in System Library Settings. I connect the ethernet cable from the development board to my computer and run the NIOS. 

 

once running the console displays: 

 

Copyright 1996-2008 by InterNiche Technologies. All rights reserved. prep_tse_mac 0 Your Ethernet MAC address is 00:07:ed:ff:c2:95 prepped 1 interface, initializing... INFO : TSE MAC 0 found at address 0x10022800 INFO : PHY Marvell 88E1111 found at PHY address 0x12 of MAC Group INFO : PHY - Automatically mapped to tse_mac_device INFO : PHY - Restart Auto-Negotiation, checking PHY link... INFO : PHY - Auto-Negotiation PASSED INFO : PHY - Checking link... INFO : PHY - Link established INFO : PHY - Speed = 1000, Duplex = Full OK, x=0, CMD_CONFIG=0x00000000 MAC post-initialization: CMD_CONFIG=0x0400020b RX descriptor chain desc (1 depth) created mctest init called IP address of et1 : 192.168.1.234 Created "Inet main" task (Prio: 2) Created "clock tick" task (Prio: 3)this all looks perfect! now i use telnet on my PC to connect to the development board at 192.168.1.234 and the console displays this: (telnet on PC times out and closes) 

dtrap - needs breakpoint panic: pktdemux: corrupt pkt dtrap - needs breakpoint ip_exit: calling func 0xc01235c netclose: closing iface Altera TSE MAC ethernet ip_exit: calling func 0xc019808any suggestions?
0 Kudos
17 Replies
Highlighted
Honored Contributor I
18 Views

more preliminary troubleshooting. Using wireshark, i can verify that my PC is querying for 192.168.1.234. I can also see the "Rx LED" light up on the development board each time my PC sends a ping request. this leads me to believe that there might be some issue with the NicheStack accessing the SGDMA module

0 Kudos
Highlighted
Honored Contributor I
18 Views

The first thing you should see in Wireshark is an ARP request. Something like "who is 192.168.1.234? Tell x.x.x.x". Do you get an ARP reply from the board giving its mac address? 

Did you do any modification or recompilation to the Quartus design, or are you using the .sof file provided with the project by Altera?
0 Kudos
Highlighted
Honored Contributor I
18 Views

I did see the arp request but no response from the development board. I did compile the FPGA project. I will look for and try the pre-compiled sof file on Monday.

0 Kudos
Highlighted
Honored Contributor I
18 Views

Do you have the license for the TSE? If not, be sure not to close the Opencores evaluation window. It would make the TSE stop working.

0 Kudos
Highlighted
Honored Contributor I
18 Views

I am seeing the same behavior on the seme dev kit running the same app under 9.1_sp1... I have a license file that says the tse nios, etc is present, however upon telnet I do not see the house of cards collapse, rather the system simply appears to be hung. Would love to work through this with all of you and perhaps post our fixes here for others rather than the typical "I got it - thanks" or the "dead-thread" that is all too prevalent on sites like this...

0 Kudos
Highlighted
Honored Contributor I
18 Views

If you're using the iniche stack, don't use the inice stack port from 9.1 sp2.  

Changes in that related to LOCK_NET_RESOURCE / UNLOCK_NET_RESOURCE are broken. In particular access to the network packets are no longer properly protected due to queue access also occurring in interrupts, in some mac drivers. 

 

The 9.1 sp1 stack also has some bugs but they are quite so bad.
0 Kudos
Highlighted
Honored Contributor I
18 Views

jcnhal (http://www.alteraforum.com/forum/member.php?u=26263) (and anyone else) - which version of the iniche stack is seen to be most stable to date? Does anyone have/maintain a bug list for this codebase? Might be a good thread to start...

0 Kudos
Highlighted
Honored Contributor I
18 Views

9.1 sp1 is pretty good but we've still had to patch it to get it to work. 

it's working pretty well for us on multiple devices with a reasonable number of network threads active simultaneously. 

without patches 9.1sp1 will crash immediately if your application uses ucos's mutexes. yo also have to make sure to create the appropriate thread semaphores for each thread. 

I've applied patches to 9.1sp2 that revert most of the code back to 9.1sp1. 

i can post the patch files if anyone is interested.
0 Kudos
Highlighted
Honored Contributor I
18 Views

 

--- Quote Start ---  

9.1 sp1 is pretty good but we've still had to patch it to get it to work. 

it's working pretty well for us on multiple devices with a reasonable number of network threads active simultaneously. 

without patches 9.1sp1 will crash immediately if your application uses ucos's mutexes. yo also have to make sure to create the appropriate thread semaphores for each thread. 

I've applied patches to 9.1sp2 that revert most of the code back to 9.1sp1. 

i can post the patch files if anyone is interested. 

--- Quote End ---  

 

 

I would definitely be interested. It would be lovely to get something working that i can start from. In the end i just need UDP so i may try to see if i can work with the TSE directly though it seems like that will be a HUGE task. 

 

PS: i tried the original .sof file and the board behaved the same as when i used my compiled .sof. and i am familiar with using the evaluation versions of blocks(ie keeping the little window open and JTAG connected during use)
0 Kudos
Highlighted
Honored Contributor I
18 Views

I agree - a baseline would be a wonderful thing... I believe I had it working using 9.1 web edition without a service pack installed, but am not certain about this... if I recall the SOPC builder was like the one I am using now (which is the nioswiki base hw for the 3c120 kit) but WITHOUT the display device... was a pared down version of the nioswiki linux-capable platform. 

 

I am attempting a build using 9.1 web (no sp installed) to see where I get. 

 

 

There's a ftp site that you can get older rev install files. 

ftp://ftp.altera.com/outgoing/release/ 

you have to decipher the release using the names of the files. 

 

Chris
0 Kudos
Highlighted
Honored Contributor I
18 Views

 

Seems like my code is getting to the blocking select() below and hanging... wondering what is happening or not happening - anyone? 

 

FD_ZERO(&readfds); 

FD_SET(fd_listen, &readfds); 

max_socket = fd_listen+1; 

 

if (conn.fd != -1) 

FD_SET(conn.fd, &readfds); 

if (max_socket <= conn.fd) 

max_socket = conn.fd+1; 

 

select(max_socket, &readfds, NULL, NULL, NULL); 

 

0 Kudos
Highlighted
Honored Contributor I
18 Views

I'm using Quartus/Nios 9.0 and know it works...  

 

I too had some trouble with hangs in select() calls, and had to change a define in ipport.h. Have a look at this message (http://www.alteraforum.com/forum/showpost.php?p=76102&postcount=5). 

I'm not sure this "cure" works with 9.1 though...
0 Kudos
Highlighted
Honored Contributor I
18 Views

i tried uncommenting the define you mentioned and recompiled and got this: 

Linking simple_socket_server.elf... /cygdrive/c/PROJECTS/CycloneProject/cycloneIII_3c120_dev_niosII_standard/software/simple_socket_server_syslib/Debug/libsimple_socket_server_syslib.a(tk_crnos.o)(.text+0x90): In function `tcp_sleep': /cygdrive/c/altera/91/nios2eds/components/altera_iniche/UCOSII/src/misclib/tk_crnos.c:85: multiple definition of `tcp_sleep' /cygdrive/c/PROJECTS/CycloneProject/cycloneIII_3c120_dev_niosII_standard/software/simple_socket_server_syslib/Debug/libsimple_socket_server_syslib.a(netmain.o)(.text+0x1e8):/cygdrive/c/altera/91/nios2eds/components/altera_iniche/UCOSII/src/misclib/netmain.c:547: first defined here /cygdrive/c/altera/91/nios2eds/bin/nios2-gnutools/H-i686-pc-cygwin/bin/../lib/gcc/nios2-elf/3.4.6/../../../../nios2-elf/bin/ld: Warning: size of symbol `tcp_sleep' changed from 236 in /cygdrive/c/PROJECTS/CycloneProject/cycloneIII_3c120_dev_niosII_standard/software/simple_socket_server_syslib/Debug/libsimple_socket_server_syslib.a(netmain.o) to 360 in /cygdrive/c/PROJECTS/CycloneProject/cycloneIII_3c120_dev_niosII_standard/software/simple_socket_server_syslib/Debug/libsimple_socket_server_syslib.a(netmain.o) /cygdrive/c/PROJECTS/CycloneProject/cycloneIII_3c120_dev_niosII_standard/software/simple_socket_server_syslib/Debug/libsimple_socket_server_syslib.a(tk_crnos.o)(.text+0x1f8): In function `tcp_wakeup': /cygdrive/c/altera/91/nios2eds/components/altera_iniche/UCOSII/src/misclib/tk_crnos.c:146: multiple definition of `tcp_wakeup' /cygdrive/c/PROJECTS/CycloneProject/cycloneIII_3c120_dev_niosII_standard/software/simple_socket_server_syslib/Debug/libsimple_socket_server_syslib.a(netmain.o)(.text+0x2d4):/cygdrive/c/altera/91/nios2eds/components/altera_iniche/UCOSII/src/misclib/netmain.c:581: first defined here /cygdrive/c/altera/91/nios2eds/bin/nios2-gnutools/H-i686-pc-cygwin/bin/../lib/gcc/nios2-elf/3.4.6/../../../../nios2-elf/bin/ld: Warning: size of symbol `tcp_wakeup' changed from 132 in /cygdrive/c/PROJECTS/CycloneProject/cycloneIII_3c120_dev_niosII_standard/software/simple_socket_server_syslib/Debug/libsimple_socket_server_syslib.a(netmain.o) to 240 in /cygdrive/c/PROJECTS/CycloneProject/cycloneIII_3c120_dev_niosII_standard/software/simple_socket_server_syslib/Debug/libsimple_socket_server_syslib.a(netmain.o) /cygdrive/c/PROJECTS/CycloneProject/cycloneIII_3c120_dev_niosII_standard/software/simple_socket_server_syslib/Debug/libsimple_socket_server_syslib.a(tk_crnos.o)(.text+0xb4): In function `tcp_sleep': /cygdrive/c/altera/91/nios2eds/components/altera_iniche/UCOSII/src/misclib/tk_crnos.c:91: undefined reference to `global_TCPwakeup_set' /cygdrive/c/PROJECTS/CycloneProject/cycloneIII_3c120_dev_niosII_standard/software/simple_socket_server_syslib/Debug/libsimple_socket_server_syslib.a(tk_crnos.o)(.text+0xb8):/cygdrive/c/altera/91/nios2eds/components/altera_iniche/UCOSII/src/misclib/tk_crnos.c:91: undefined reference to `global_TCPwakeup_set' /cygdrive/c/PROJECTS/CycloneProject/cycloneIII_3c120_dev_niosII_standard/software/simple_socket_server_syslib/Debug/libsimple_socket_server_syslib.a(tk_crnos.o)(.text+0xd8):/cygdrive/c/altera/91/nios2eds/components/altera_iniche/UCOSII/src/misclib/tk_crnos.c:93: undefined reference to `global_TCPwakeup_set' /cygdrive/c/PROJECTS/CycloneProject/cycloneIII_3c120_dev_niosII_standard/software/simple_socket_server_syslib/Debug/libsimple_socket_server_syslib.a(tk_crnos.o)(.text+0xdc):/cygdrive/c/altera/91/nios2eds/components/altera_iniche/UCOSII/src/misclib/tk_crnos.c:93: undefined reference to `global_TCPwakeup_set' /cygdrive/c/PROJECTS/CycloneProject/cycloneIII_3c120_dev_niosII_standard/software/simple_socket_server_syslib/Debug/libsimple_socket_server_syslib.a(tk_crnos.o)(.text+0xf8):/cygdrive/c/altera/91/nios2eds/components/altera_iniche/UCOSII/src/misclib/tk_crnos.c:94: undefined reference to `global_TCPwakeup_set' /cygdrive/c/PROJECTS/CycloneProject/cycloneIII_3c120_dev_niosII_standard/software/simple_socket_server_syslib/Debug/libsimple_socket_server_syslib.a(tk_crnos.o)(.text+0xfc):/cygdrive/c/altera/91/nios2eds/components/altera_iniche/UCOSII/src/misclib/tk_crnos.c:94: more undefined references to `global_TCPwakeup_set' follow /cygdrive/c/PROJECTS/CycloneProject/cycloneIII_3c120_dev_niosII_standard/software/simple_socket_server_syslib/Debug/libsimple_socket_server_syslib.a(tk_crnos.o)(.text+0x118): In function `tcp_sleep': /cygdrive/c/altera/91/nios2eds/components/altera_iniche/UCOSII/src/misclib/tk_crnos.c:95: undefined reference to `global_TCPwakeup_setIndx' /cygdrive/c/PROJECTS/CycloneProject/cycloneIII_3c120_dev_niosII_standard/software/simple_socket_server_syslib/Debug/libsimple_socket_server_syslib.a(tk_crnos.o)(.text+0x118):/cygdrive/c/altera/91/nios2eds/components/altera_iniche/UCOSII/src/misclib/tk_crnos.c:95: Unable to reach global_TCPwakeup_setIndx (at 0x00000000) from the global pointer (at 0x0c0520dc) because the offset (-201662684) is out of the allowed range, -32678 to 32767. collect2: ld returned 1 exit status make: *** Error 1 looks like this causes: multiple definition of `tcp_wakeup()' and `tcp_wakeup()' as these were originally defined in tk_crnos.c but when using this define they are redefined in netmain.c
0 Kudos
Highlighted
Honored Contributor I
18 Views

Guys I too face the similar problem. 

Go through the attached snapshot of error and suggest me the solution
0 Kudos
Highlighted
Honored Contributor I
18 Views

fire a debugger and put a breakpoint on dtrap() to see what is causing it.

0 Kudos
Highlighted
Honored Contributor I
18 Views

Hi folks, 

I am using Arria II GX on my custom board 

I am making my custom board as CLIENT and one host PC as SERVER to establish communication between client and server using socket programming. 

I am using MARVELL PHY 88E1111 on my custom board, Triple Speed Ethernet MAC in my SOPC builder design 

I have attached snapshot of my SOPC bulider design, Please go through it and let me know if any problem in SOPC builder design. 

 

I created a client program in Nios II SBT for Eclipse and tried to run as hardware on my custom board. 

I am able to configure my custom board with static IP address, I can ping my custom board successfully with the IP address I configured. 

socket gets created on the board, after this client program on custom board tries to connect to server on my PC, but..... 

connect never happens.... 

I have also attached snapshot of whatever I see in NIOS II console. 

sometimes I get error message as 

dtrap - needs breakpoint 

panic: pktdemux: corrupt pkt 

dtrap: needs breakpoint 

ip_exit: calling func 0x1141eb30 

netclose: closing iface Altera TSE MAC Ehernet 

ip_exit: calling func 0x114126ef0 

well sometimes I get error as 

No free buffers for rx 

No free buffers for rx 

...................... 

...................... 

...................... 

No free buffers for rx 

 

Please go through my attached snapshots and suggest me the possible solutions.
0 Kudos
Highlighted
Honored Contributor I
18 Views

put a breakpoint on the dtrap() function and use the debugger to find out where the call came from. If you are lucky you may find a helpful comment in the code saying why dtrap() was called. 

And don't post the same question multiple times
0 Kudos