Forum Discussion
Altera_Forum
Honored Contributor
13 years agoProblems with Cyclone IV and DP83848C
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.1copyright 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
27 Replies
- Altera_Forum
Honored Contributor
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] - Altera_Forum
Honored Contributor
--- 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?
- Altera_Forum
Honored Contributor
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?
- Altera_Forum
Honored Contributor
--- 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? - Altera_Forum
Honored Contributor
--- 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) - Altera_Forum
Honored Contributor
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. - Altera_Forum
Honored Contributor
--- 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!