- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- « Previous
-
- 1
- 2
- Next »
27 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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]- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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!
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »