Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
782 Views

Ethernet on Bemicro SDK

I'm trying to port the standard net example onto the BeMicroSDK which uses the DP83848C PHY. 

 

To keep it simple, I've disabled DHCP and hard-coded a Static IP for now. Everything seems to synthesize, and compile OK but fails on Auto-Negotiation when connected to the Host PC with a crossover cable: 

 

Static IP Address is 10.10.1.149 prepped 1 interface, initializing... INFO : TSE MAC 0 found at address 0x04000000 INFO : PHY National DP83848C found at PHY address 0x17 of MAC Group INFO : PHY - Automatically mapped to tse_mac_device INFO : PHY - Restart Auto-Negotiation, checking PHY link... WARNING : PHY - Auto-Negotiation FAILED INFO : PHY - Checking link... INFO : PHY - Link not yet established, restart auto-negotiation... INFO : PHY - Restart Auto-Negotiation, checking PHY link... WARNING : PHY - Auto-Negotiation FAILED WARNING : PHY - Link could not established WARNING : PHY - Auto-Negotiation not completed! Speed = 100, Duplex = Full OK, x=0, CMD_CONFIG=0x00000000  

 

Unlike the NEEK development platform (Lan91c111 PHY), which connects the sgdma to DDR and external SRAM, the BeMicro only has DDR. I suspect it's related to the SGDMA/TSE_mac. 

 

What addresses does sgdma_rx write to when it receives ethernet data from the tse_mac? I don't see anywhere in qsys nor the code that defines where the sgdma sram/ddr writes are, but perhaps Nios code/stack is occupying the same area.  

 

Any where else I should look at?
0 Kudos
5 Replies
Altera_Forum
Honored Contributor I
46 Views

For what it's worth, auto-negotiation does not involve packet transmit/receive. It's a function performed within the PHY, and the NIOS software determines it's success/failure by reading the PHY status registers via the MDIO. Your problem might be something simple like the cable or possibly a bad pin assignment (although if it were a bad pin assignment I'm not sure you would have gotten that far). 

 

Regarding SRAM, I believe the standard ethernet example (and also my BeMicro SDK projects) have onchip SRAM for SGDMA descriptor storage; the packets themselves are in DDR however. If you are following the standard example, you shouldn't have any trouble like memory corruption.
Altera_Forum
Honored Contributor I
46 Views

I wanted to avoid a hub/switch + patch cable to the equation.. but perhaps it's a worthwhile test to eliminate the crossover-cable (I only have 1). 

 

The descriptor storage uses on-chip ram, but how do the packets get placed in DDR while avoiding the Nios execution code? Since the linker script doesn't show the code to be bound to a certain area in DDR, isn't this dangerous?
Altera_Forum
Honored Contributor I
46 Views

Regarding cables, the problem could also be something like your host PC ethernet adapter had been configured to not auto-negotiate (for example, if you had previously set it to operate only in gigabit modes). This also is easy enough to confirm/deny with a switch. 

 

Regarding packet storage, the software uses malloc() etc. to allocate packet storage space from the heap.
Altera_Forum
Honored Contributor I
46 Views

 

--- Quote Start ---  

the problem could also be something like your host PC ethernet adapter had been configured to not auto-negotiate  

--- Quote End ---  

 

 

Not sure why, as all the settings match, but I changed computers and the auto-negotation now passes: 

 

-->Your Ethernet MAC address is 00:07:ed:ff:cd:15 Static IP Address is 10.10.1.150 prepped 1 interface, initializing... INFO : TSE MAC 0 found at address 0x04000000 INFO : PHY National DP83848C found at PHY address 0x17 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=3, CMD_CONFIG=0x00000000 MAC post-initialization: CMD_CONFIG=0x04000203 RX descriptor chain desc (1 depth) created mctest init called IP address of et1 : 10.10.1.150 Created "Inet main" task (Prio: 2) Created "clock tick" task (Prio: 3) Created "web server" task (Prio: 4) Web Server starting up  

 

However, the same computer that's connected to the BeMicro, time's out when I enter its (static) ip address in the browser.  

 

I was thinking the problem has to do with the file system , since the NEEK boards store the webpage zip in flash, and on the BeMicro I'm just linking it as an object into ddr.  

 

However, putting a breakpoint in WSTask() where it waits a incomming connection on the listening socket, but it never gets there. Without any error message on the console, I'm not sure if it's on the logic/nios side or if the pc request isn't getting to it. 

 

Only the single wired NIC is connected to the BeMicro, with the PC TCP/IP setting set for a static IP 10.10.1.2, subnet 255.255.255.0, gateway of 10.10.1.1... the BeMicro set for a static IP of 10.10.1.150. 

 

Maybe WireShark can see for sure if there's traffic, but any obvious reason why there would be the webserver wouldn't work despite the mac/phy reporting auto-negotation and link established?
Altera_Forum
Honored Contributor I
46 Views

Closer! 

 

Fired this up today, and found that having the wifi and and the wired ethernet on at the same time is a bad idea.. 

 

Disabling the wifi, so that only the wired connection (which is connected to the bemicro) the Nios gets to the WSTask breakpoint that detects socket activity! 

 

Nothing gets served up, but at least I have an error now to track down: 

 

ins_tse_mac.c : tse_mac_rcv reports "No free buffers for rx" 

 

Which looks like using the default heap settings is not correct for the bemicro, or something in the memory hookup in qsys.
Reply