LAN8720A Issues (SOLVED)

[lpcware]

Content originally posted in LPCWare by jnewell on Mon Sep 09 08:15:57 MST 2013
Hello, I'm just wondering if anyone out there has created a custom board with a LAN8720A.
I'm having problems with getting the 25MHz crystal to run.
I have attached the schematic that I am using.

Any Help/info would be appreciated.

Thanks,
Josh

[lpcware]

Content originally posted in LPCWare by capiman on Mon Jan 06 11:38:37 MST 2014
@Mike:
There was just a release of a new user manual for LPC176x/5x:

http://www.lpcware.com/content/nxpfile/lpc17xx-user-manual

and guess what was changed: Search for "Ethernet Packet Fields"...

[lpcware]

Content originally posted in LPCWare by jnewell on Tue Sep 17 07:34:21 MST 2013
Hey everyone,

I have got the PHY working exactly how it is supposed to now!

replacing the Inverter did the trick. I must have got a bad IC or something.

It allows me to ping and telnet into it without any problems.

Thanks for the help everyone.

-Josh

[lpcware]

Content originally posted in LPCWare by jnewell on Tue Sep 17 05:55:42 MST 2013
Wow you guys sure commented a lot since yesterday.

Just so you know, I am running the same exact software on both boards(pretty much programmed one, then plugged the other in and programmed it, without any modifications to the code)

I'm suspecting that the inverter(SN74LVC1G04) on the reference clock going from the PHY to the LPC1768 is the problem.

I had previously contacted SMSC and sent them my schematic to have it checked out. They recommended that I remove the inverter(SN74LVC1G04) from my board for it to work correctly, so I took it off and connected the input and output lines to the inverter with a jumper.

Yesterday, I thought I'd check and see if the Inverter was completely necessary, so I removed it from the eval board and got it to replicate the situation I'm having with my custom board.

Going to put the inverter back on my custom board, and float the output pin to make sure that the inverter is even working correctly.

-Josh

[lpcware]

Content originally posted in LPCWare by capiman on Tue Sep 17 00:59:10 MST 2013
Same for me, i don't know.
I will forward it to NXP for clarification, report it back, when i receive something!

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Tue Sep 17 00:56:24 MST 2013
What that implies is that the first 48 bits (6 bytes) get reversed, so do the next 6 bytes,
but NONE of the rest of the packet.

I am not a hardware person, but that sounds a bit ridiculous.
Perhaps there is a scope image of a ethernet transfer on the
physical wires to prove/deny this, but I don't (even need to) know
the signaling waveforms or how the translate back to 'bits'.

Mike

[lpcware]

Content originally posted in LPCWare by capiman on Tue Sep 17 00:47:26 MST 2013
I think i agree with you!

But just in case if NXP has counted the other way round:
Then UM figure 22 would be ok, because our first byte is their last byte?
And the value you put into Station Register ZERO is byte zero and one, so correct order?

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Tue Sep 17 00:27:57 MST 2013
The UM figure clearly shows 'octet 6' being transmitted first.
for my MAC address, that is 'C6' (The sixth byte of the address.)
Wireshark and the debugger show the first byte sent or received is
'00' followed by '04' then '3A' etc. with 'C6' last.
See atached snap.

Hence figure 22 is wrong by my reckoning.

I know the each BYTE is transmitted LS BIT first, but the bytes are
transmitted in first to last order. [At least, that is how they end
up in memory.]

And you can't get away from the fact that the fith and sixth bytes of the
MAC address have to be put is Station Register ZERO to make it work.

What say you? Mike

[lpcware]

Content originally posted in LPCWare by capiman on Mon Sep 16 23:13:54 MST 2013
I think figure 22 looks ok. Or have I overseen something?
When just comparing the values of figure 22 against a wireshark trace, I think the both are consistent,
e.g. DesA oct 6 is transmitted first in packet and also in wireshark decoding of address.
Is it perhaps a problem what is assumed as first byte (the MSB or LSB)?

What i haven't looked at: Are perhaps Station Address Register SA0,SA1,SA2 not consistent to figure22?
So is the value you write into SA0 Bit 15:8 really the oct1 mentioned in figure 22.
Is this what you mean, that there is an error?

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Mon Sep 16 22:22:44 MST 2013
UM10470 rev 2.1 (6-Mar-13) section 10.7; figure 22 is false to fact!
MAC addresses are transmitted oct1m oct2, ... oct6
This is shown by the dumps in wireshark and in packet dumps in my
firmware in the debugger.

E.g: my board;s MAC is 00:04:A3:3B:D7:C6

[Code]
movsr1, memBase; get MAC addr from eeprom cache
ldrhr0, [r1, eMac+4]; last   2 digits ABCD[EF]
strr0, [r7, netMacAddr0];
ldrhr0, [r1, eMac+2]; middle 2 digits AB[CD]EF
strr0, [r7, netMacAddr1];
ldrhr0, [r1, eMac+0]; first  2 digits [AB]CDEF
strr0, [r7, netMacAddr2];

movsr0, 0x26; unicast/multicast/broadcast
strr0, [r7, netRxFltCtrl];
[/Code]

Note how the valuses are in reverse order to the EMAC registers!

Cheers, Mike

[lpcware]

Content originally posted in LPCWare by capiman on Mon Sep 16 22:10:48 MST 2013
@Mike:
Can you give me a reference in which User Manual (which LPC)
this error/the wrong section is?

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Mon Sep 16 22:06:13 MST 2013
Is the emac code exactly the same on the Code Red eval board and your custom board?

I had to reverse the MAC address when I put it in the EMAC 'Station Registers'
(the user manual has a section that is complete and utter bullsh1t!)
Also, in the receive fiter register, set multicast AND broadcast -- one is a superset
of the other, I can't remember which way round -- as well as unicast.

You do know that if your board dosn't answer ARP broardcasts that the other end will
not send the ping echo request (or udp or tcp) don't you.

Finally, in your receive interrupt, recheck for received packets till all are seen.
Otherwise you will miss packets and never be in sync.

Cheers, Mike

Clarification, i.e. NOT reverse the MAC addr like the manual claims you must!
'Reverse' above means oposite to what the UM10470 says!

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Mon Sep 16 21:54:57 MST 2013
For your wireshark filter, try "ip.addr == xxxxxx or arp"
to confirm your board handles arp correctly.
Here is a capture for my setup.

[lpcware]

Content originally posted in LPCWare by jnewell on Mon Sep 16 12:53:07 MST 2013
Well, I hooked back up my RDB1768 Eval board, to compare the output of Wireshark, and here's what I got. It pings just fine, and also connects to telnet just fine.
I'm thinking that there is just something the PHY doesn't like about my custom schematic still.

-Josh

[lpcware]

Content originally posted in LPCWare by jnewell on Mon Sep 16 07:45:41 MST 2013
I've tried a few things, nothing is received by the LPC.

[lpcware]

Content originally posted in LPCWare by capiman on Mon Sep 16 06:49:14 MST 2013
But there is also no ping in your screenshot, so your PC is not sending the ping?
Have you tried if you are receive something (does not matter what) on your LPC?
Usually there are broadcasts, ARP, ... which the LPC receives? Does it?

[lpcware]

Content originally posted in LPCWare by jnewell on Mon Sep 16 06:41:57 MST 2013
Well here is my wireshark capture. I've got the software sending 5 udp messages to a multicast server (239.0.0.0). I am definitely receiving the messages that are sent, on my server program.
I ran the ping right after packer 2206 appeared, and there is nothing.

-Josh

[lpcware]

Content originally posted in LPCWare by capiman on Mon Sep 16 06:05:50 MST 2013
> Only thing is, it won't receive anything tcp/udp

Do you receive something at all?
Can you create a wireshark trace and upload it here?

[lpcware]

Content originally posted in LPCWare by jnewell on Mon Sep 16 06:00:14 MST 2013
That is definitely the reason, one single via just does not cut it!

Anyway,Its connecting up to my switch, and showing activity. Only thing is, it won't receive anything tcp/udp. It sends out udp just perfectly(according to wireshark). Not exactly sure why. I'm also not able to ping or telnet into it.
Kinda stumped again, thinking I might have my receive lines backwards (not using an Ethernet connector onboard, just splicing it into a ethernet cable with 2 twisted pairs from the lines that come out of the magnetics).

Has anyone else ever had this problem?

-Josh

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Fri Sep 13 23:01:09 MST 2013
I seem to remember that the PXB designer had to put several vias under the
LAN8720A MLF package -- either for ground plane reasons or heat disapation
or both.

This level of detail is way over my head, but may make sense to others.

Cheers, Mike

[lpcware]

Content originally posted in LPCWare by jnewell on Thu Sep 12 07:16:41 MST 2013

I figured out the reasoning for the 1.2V reading at 2.1V. It ended up that the ground pad on the LAN8720 wasn't getting a good connection.
Unfortunately it still isn't working although the correct voltage is on VDDCR.

Thanks Mike for the reference