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++
12589 Discussions

Problems with Cyclone IV and DP83848C

Altera_Forum
Honored Contributor II
3,172 Views

Dear all, I've made my own board of Cyclone IV EP4CGX110CF23C7. And i want to make a ethernet module with DP83848C which is surpported by the TSE core.  

However, when i have completed my SOPC system and downloaded the nios program, it seems that something wrong happened to my program and i am confused  

by this problem for several days. When i run my project as NIOSII hardware on NIOS SBT v12.1, the nios ii console displays as following: 

 

interniche portable tcp/ip, v3.1  

copyright 1996-2008 by interniche technologies. all rights reserved.  

prep_tse_mac 0 

your ethernet mac address is 00:16:36:fc:14:2d 

static ip address is 192.168.1.234 

prepped 1 interface, initializing... 

netinit: calloc failed getting buffer 17 

inet startup error: unable to initialize net 

panic: ip 

dtrap - needs breakpoint 

ip_exit: calling func 0x9e7a4 

 

Here are some attachments of my program.  

PS: 1. I turned off the DHCP and set the board IP address 192.168.1.234. 

2. I created the program from the template Simple Socket Server.  

3. There is no NAND flash on my board and i set my board MAC address 00:16:36:fc:14:2d
0 Kudos
27 Replies
Altera_Forum
Honored Contributor II
187 Views

Yes, it looks like the packet is ignored by the TSE. Here are a few questions 

 

[list][*]Is ETH_RXCLOCK connected to the correct port on the TSE?[*]Is the Ethernet packet well formed?[*]Is the TSE reception enabled?[*]Is it a broadcast packet[*]If it isn't a broadcast packet, is the packet's destination MAC address the same one than the TSE's?[*]could you include in your Signaltap sources the ff_rx_dval, ff_rx_sop, ff_rx_eop and ff_rx_rdy signals?[/list]
0 Kudos
Altera_Forum
Honored Contributor II
187 Views

 

--- Quote Start ---  

Yes, it looks like the packet is ignored by the TSE. Here are a few questions 

 

  • Is ETH_RXCLOCK connected to the correct port on the TSE? 

  • Is the Ethernet packet well formed? 

  • Is the TSE reception enabled? 

  • Is it a broadcast packet 

  • If it isn't a broadcast packet, is the packet's destination MAC address the same one than the TSE's? 

  • could you include in your Signaltap sources the ff_rx_dval, ff_rx_sop, ff_rx_eop and ff_rx_rdy signals? 

 

 

--- Quote End ---  

 

 

 

Thanks for the answer, I am back in the lab after weekend so I can analyze problem again... For your questions: 

 

- ETH_RXCLOCK is connected directly to the rx_clk port of the TSE I suppose it is OK but anyway i am attaching the .bdf file 

- If the Ethernet packet well formed... hmmm I do not know how to check it out... :( 

- TSE reception enabled... I used the simple socket server without any changes in the TSE handling so I am think it should be enabled.. but I can check it.. but do not know where 

- It is broadcast packet. In the wireshark it is marked as ARP packet with info: "Who has 192.168.0.180? Tell 192.168.0.1" 

- I have included signals as you suggested.. there is an attachment below.. 

 

Thank you for your time..  

 

https://www.alteraforum.com/forum/attachment.php?attachmentid=7802  

 

I am attaching also the Quartus 12 project for check of the Qsys system.. Maybe there is some mistake.. but I have checked it many times :(.. In the zip file was removed files after synthesis due to upload size...
0 Kudos
Altera_Forum
Honored Contributor II
187 Views

The extra signals in Signaltap are in red, which indicates that they don't exist. Are you sure you picked them from the TSE and not the top level?

0 Kudos
Altera_Forum
Honored Contributor II
187 Views

 

--- Quote Start ---  

The extra signals in Signaltap are in red, which indicates that they don't exist. Are you sure you picked them from the TSE and not the top level? 

--- Quote End ---  

 

 

I have just use F2 to rename them but I will make clean new SignalTap tommorow morning to ensure that the signals are actual.. Did you find something wrong in the attached project?
0 Kudos
Altera_Forum
Honored Contributor II
187 Views

 

--- Quote Start ---  

The extra signals in Signaltap are in red, which indicates that they don't exist. Are you sure you picked them from the TSE and not the top level? 

--- Quote End ---  

 

 

 

Okey, please find fixed signal_tap output below. I suppose the TSE completely ignore the receivement... Just for notice I run the NIOS code before I caught the data in the signaltap: 

 

https://www.alteraforum.com/forum/attachment.php?attachmentid=7806  

 

To remind the console output of the NIOS build is here: 

 

InterNiche Portable TCP/IP, v3.1 Copyright 1996-2008 by InterNiche Technologies. All rights reserved. prep_tse_mac 0 Can't read the MAC address from your board. We will assign you a MAC address. Please enter your 9-digit serial number. This is printed on a label under your Nios dev. board. The first 3 digits of the label are ASJ and the serial number follows this. -->Created "Inet main" task (Prio: 2) Created "clock tick" task (Prio: 3) 123456789 123456789 Your Ethernet MAC address is 00:07:ed:ff:cd:15 Static IP Address is 192.168.0.180 prepped 1 interface, initializing... INFO : TSE MAC 0 found at address 0x10001000 INFO : PHY National DP83848C found at PHY address 0x01 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 = 100, Duplex = Full OK, x=0, CMD_CONFIG=0x00000000 MAC post-initialization: CMD_CONFIG=0x04000203 RX descriptor chain desc (1 depth) created mctest init called IP address of et1 : 192.168.0.180 Simple Socket Server starting up Simple Socket Server listening on port 30 Created "simple socket server" task (Prio: 4)
0 Kudos
Altera_Forum
Honored Contributor II
187 Views

Yes, it looks like the TSE isn't sending the packet further, which is odd because it looks like a broadcast packet. I didn't have time to check your project yesterday, but I just did and I don't see anything wrong in it. 

I see that your driver is writing CMD_CONFIG=0x04000203. It does enable both tx and rx, but it also sets RX_ERR_DISC, that tells the TSE to discard erroneous frames. Usually this is better, but in order to debug your system you could try and set it to 0 (CMD_CONFIG=0x00000203) and see if something gets sent. 

You can also enable the statistics (in the TSE settings in QSys) and then read the counters from your software to see if anything changes.
0 Kudos
Altera_Forum
Honored Contributor II
187 Views

 

--- Quote Start ---  

Yes, it looks like the TSE isn't sending the packet further, which is odd because it looks like a broadcast packet. I didn't have time to check your project yesterday, but I just did and I don't see anything wrong in it. 

I see that your driver is writing CMD_CONFIG=0x04000203. It does enable both tx and rx, but it also sets RX_ERR_DISC, that tells the TSE to discard erroneous frames. Usually this is better, but in order to debug your system you could try and set it to 0 (CMD_CONFIG=0x00000203) and see if something gets sent. 

You can also enable the statistics (in the TSE settings in QSys) and then read the counters from your software to see if anything changes. 

--- Quote End ---  

 

 

Thank you for your time and help.. I did not solve the problem with the DP83848C PHY but on my board I have designed also the SFP cage with the SFP module for optical and copper ethernet modularity. When the DP83848C had problems I have just tried to enable the GX transciever and try if the TSE will work with the SFP modules.. And :) for my surprise it is working like a charm. The design od DP83848C has been taken only as a backdoor if the SFP will no work on the board, but suddenly the situation is vice-versa and everything is OK.. But anyway thank you for your time and helpful answers!
0 Kudos
Reply