Ethernet on Bemicro SDK

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.

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?

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.

--- 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?

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.