Trouble making networking work with National Semiconductor DP83848J PHY

[Altera_Forum]

I'm still working on getting networking going on my soft processor. I've made  

a lot of progress but currently have exhausted my ideas for troubleshooting.  I'm hoping the veterans of the forum might have suggestions.  What I have is a cyclone II based board with SDRAM, flash, and SSRAM. The  SDRAM is known good, it has passed memory tests and I am not yet attempting to  use the flash or SSRAM.  I have a DP83848J-MAU-EK (note the J is relevant, not the C that other designs  have used) from National Semiconductor  (http://www.national.com/pf/dp/dp83848j.html#boards). It is an evaluation  board for the DP83848J and it has a single header carrying 3.3V, ground, and  the MII signals. I have a cable that brings these MII connections directly to  my FPGA with no buffers or pull ups.   I also have two different development kits that use a similar chip for their  PHY. I have the BeMicro SDK and I have the NIOS Embedded Evaluation Kit (aka  NEEK). Both these board have a National Semiconductor DP83848C Phy chip with  the MII signals wired directly to the FPGA.   The problem is that I simply cannot get the PHY to work on my board. I have  run two different operating systems, the "Micrium on Altera Hardware  Abstraction Layer" and Linux 2.6.37. I also have two separate soft MAC's I  have tried, the Altera Triple Speed Ethernet MAC and the Avalon "Igor Open  Cores Mac". I have been able to make all four combinations of MAC and OS work  on both my development kits. But not on my hardware.  The failure mode is interesting because it passes all the phy initializations  and does not indicate any error initializing or attaching the PHY to the MAC.  But it simply does not send or receive any traffic.  I have monitored the MDIO bus with signatap and I can clearly see the MAC  scanning the MDIO bus for a phy at various addresses and then initializing the  phy when it finds one at a valid address. I have decoded dozens of MDIO bus  transactions and they all look textbook perfect to my (limited) experience.  I have connected a computer directly to the network port of the PHY and  monitored all bus traffic with Wireshark. If I ping from my computer into the  test board, I clearly see exactly what I would expect with RXDV rising and the  data lines clocking data.  If I ping out from the test board, I see TXEN rise and the data clock out on  the TXD lines.  I've wired up a test source project and verified that all signals are routed to  the correct pins on the Phy board.   I've chased down a couple of leads that led no where. At first I was getting  the PHY "strapped" in at a wierd address, it was being recognized at address  0x1F. I eventually tracked that down and corrected it but it made no  difference. It was responding the same at address 1 as 0x1F.  I thought maybe that the fact the Phy Evaluation board did not connect the Phy  reset signal might be causing the Phy to come up in an odd state. So we  soldered a jumper from an unused pin on the header to the reset pin but it did  not change the behavior of the system to reset the phy prior to initialization  (other than it did clear up the odd address getting strapped into the Phy).  I'm left with two theories: Either the hardware is "defective" in some subtle way or there is something  about the "J" revision of the chip that breaks the drivers in both operating  systems. The two chips do have separate data sheets:  http://www.national.com/ds/dp/dp83848c.pdf http://www.national.com/ds/dp/dp83848j.pdf But according to the migration application note, the differences should not  affect the software drivers because all the "core" registers are the same.  http://www.national.com/an/an/an-1854.pdf.  I have no problem building hardware and software packages from scratch for  either the BeMicro or the NEEK and can make networking work on both platforms  for all four possible combinations of OS and soft MAC. But on my hardware  connected to that evaluation kit board, I get "silent failure" on all four  possible combinations. No errors indicated, no warnings, just no traffic sent  or received.  Sorry for the long winded email, just looking for any suggestions of how you  might test or instrument the system for more answers. On Monday I'm ordering  a DP83848C evaluation kit if I can find one in stock.  Any suggestions welcome and thanks for your time. David

[Altera_Forum]

I believe that for most the demo boards, Altera uses the Marvel physical. After the MAC initializes the physical, does the part auto-negotiate correctly with the PC? I suspect this is the case, if you can send pings and see the TX and RX signals toggle. I would recheck the bit order on the port to ensure that the data is not being corrupted. The MAC's will drop any packet that is not have a good CRC. I am sure that you already have done this.  

 Also, I would hook up a two memories to the RX/TX ports with a counter driving the address when RX_EN and TX_EN is valid. When you instantiate the memory, check the box that you want to view the memory with JTAG. Use the memory tool to look at the messages being passed. This is like a built in packet sniffer. This may help you figure out what is going on.

[Altera_Forum]

--- Quote Start ---  I believe that for most the demo boards, Altera uses the Marvel physical. After the MAC initializes the physical, does the part auto-negotiate correctly with the PC? .  --- Quote End ---    Yes, the part finishes the auto negotiation and correctly identifies the link as 100 Base T.    --- Quote Start ---   I suspect this is the case, if you can send pings and see the TX and RX signals toggle. I would recheck the bit order on the port to ensure that the data is not being corrupted. The MAC's will drop any packet that is not have a good CRC. I am sure that you already have done this.  --- Quote End ---   Good idea... but I don't think that is the issue. If the data were corrupted due to bit order, I would see the error count increasing when I do an "ifconfig eth0" in Linux. Also if it were a bit order problem, I would see some data on Wireshark coming out of the port but I get total silence.     --- Quote Start ---   Also, I would hook up a two memories to the RX/TX ports with a counter driving the address when RX_EN and TX_EN is valid. When you instantiate the memory, check the box that you want to view the memory with JTAG. Use the memory tool to look at the messages being passed. This is like a built in packet sniffer. This may help you figure out what is going on.  --- Quote End ---   This sounds like a neat trick. Have not done that but I will try to figure it out. You instantiate memories inside NIOS or on the top level design? Thanks for your time.  David

[Altera_Forum]

The MII control signals will run at a much lower speed than the data signals. So maybe there is something wrong with the data clock? 

 Might be worth forcing the PHY to work at 10M - which will slow down the MII data clock. If you can, set the PHY's ANAR (autonegotiate adverstise register) to only allow 100M FDX since that will complete auto negotiation to 10M, if you plug into an old 10M hub it will autodetect 10M and the device driver may get confused (it will probably read stale data from the ANRR and set the wrong speed!).

[Altera_Forum]

So I had some success... I found some noise on one signal and changed some cabling and now I can transmit from my board out. When I ping from my board (running linux) I can clearly see the output in wireshark on my PC and my PC responding. But the replies are not seen by my board. 

 I then tried switching to an MMU-less design and testing under Micrium + HAL with their simple socket server. The simple socket server completes all MAC initialization steps and reports no errors. But again, when I attempt to connect no response for traffic inbound to my board.  So I either have a noise problem or a design problem.   I need to isolate the problem between noise, design, or driver. I think I can pretty well eliminate driver because I get the same behavior with Linux on MMU as with Micrium + HAL on no-mmu.   Any suggestions on what tools or techniques to isolate my problem?  David

[Altera_Forum]

Hi David 

I use DP83848K. I didn't compare the datasheets but I think they are basically the same device, J being the commercial grade and K the industrial.  My configuration is the following one: - sopc system with Nios and 2 opercores MACs - each MAC connects to a DP83484 PHY - MAC has MII; PHY is connected in RMII mode; so I use a MII/RMII converter - Micrium OS with InterNiche stack - TCP/IP on one Ethernet port; tx/rx raw frames on the second one.  I haven't had problems in operating the phy and it worked immediately on my prototype board. I initially had a problem similar to yours (i.e could transmit on wire but not receive) but it actually was a problem with fpga hardware and HAL drivers: the interrupt line from MAC was not connected. I'd suggest you probe the MII receive lines: if you can see data when the rx packet is being received, then the problem is not with the phy itself but in the way it has been connected to the MAC. You can debug the MAC registers and MAC driver and search for any generated rx error  Regards