Connectivity

[rikraf]

Hi All,

I have a V6 custom board with Marvell 88E1111 PHY, RGMII interface.  I believe hardware works because:

I can run a address-swap design which echoes packets from a host, using a bit of firmware

and

I can build a MicroBlaze design with LLTEMAC and LLFIFO and run the SDK-generated test_peripheral app, which puts the PHY in loopback and sends and verifies packets.

Both of these things work.  BUT, when I take the PHY out of loopback and send packets from a host, to the broadcast MAC address, for instance, all of my packets get rejected.  I can see the packet data in chipscope, and it's all correct.  But the TEMAC Interrupt Status register always sets bit RxRjct (bit 28), and the TemacPollForRxStatus() always returns an error.

Any ideas?

Thanks,

Rick

[ejanney]

The LL_TEMAC Data sheet has a list of cause for the rxrject bit to be set:

Please refer to Figure 50 on page 80 for conditions that will cause the receive frame reject interrupt to occur. The receive frame reject interrupt will occur for any of the following reasons:
A. The frame does not meet the Ethernet frame requirements as determined by the hard TEMAC core (bad FCS, bad length, etc).
B. In addition to the frame being good but not meeting the destination address filtering by the hard TEMAC, the frame also does not match one of the 4 multicast table entries, it is not a broadcast frame, it does not match the unicast address register, and the Hard TEMAC core is not in promiscuous mode.
C. The core was built to support extended multicast address filtering (C_TEMACx_MCAST_EXTEND=1), but the hard TEMAC core is not in promiscuous mode.
D. The frame is good and meets the destination address filtering by the hard TEMAC but it is a multicast frame and the multicast reject bit is set in the soft RAF register.
E. The frame is good and meets the destination address filtering by the hard TEMAC but it is a broadcast frame and the broadcast reject bit is set in the soft RAF register.

[rikraf]

Thanks for your response.

Right, I looked at that flow chart and still cannot figure out what's wrong.  The data should not be transferred to the LLFIFO if any of those conditons are true, isn't that correct?  I can see the data being transferred to the FIFO (in chipscope).  Maybe the receive frame reject is happening on an earlier,  bad, frame, and the later frame (which I see in Chipscope) is good, ...

Rick

[rikraf · Accepted solution]

I figured this out.  I was not *clearing* the RxRjct bit after a bad packet was detected (it was only bad because it was directed to neither the broadcast nor the uncast address), so the code would never get to XST_SUCCESS, so never read out the FIFO.

Rick