LPC Board is not pinging

lpcware · ‎06-15-2016

Content originally posted in LPCWare by aarthi on Sun Jul 31 22:56:42 MST 2011
Hi
I tried the easyweb example code given in the IDE for ethernet communication.Eventhough i have given the correct IP Address, MAC address i am not able to communicate with the board:confused:

lpcware · ‎06-15-2016

Content originally posted in LPCWare by aem.nitin on Sat Dec 06 03:48:29 MST 2014
Dear Ajabo,

Can you please share a sample project over UDP so that I can utilize your efforts in my application ?
I shall be highly thankful to you.
Please help

Br

Nitin

lpcware · ‎06-15-2016

Content originally posted in LPCWare by FlySnake on Fri Dec 02 08:42:48 MST 2011

Quote: Zero
Congratulation and welcome to the club :rolleyes:

This error is known since February:

See #35 of http://knowledgebase.nxp.com/showthread.php?t=1495&page=4

You do not talk about club :)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Fri Dec 02 03:09:51 MST 2011
Congratulation and welcome to the club :rolleyes:

This error is known since February:

See #35 of http://knowledgebase.nxp.com/showthread.php?t=1495&page=4

lpcware · ‎06-15-2016

Content originally posted in LPCWare by FlySnake on Fri Dec 02 02:56:36 MST 2011
If this is already actual problem with easyweb and ping, there is a possible solution:

Quote:
The actual echo reply differs from the request and this cause the ping program doesn't work. The problem is in source file tcpip.c in function PrepareICMP_ECHO_REPLY(), started line 832 from // ICMP comment:

*(unsigned short *)&TxFrame2[ICMP_TYPE_CODE_OFS] = SWAPB(ICMP_ECHO_REPLY <<  8);
*(unsigned short *)&TxFrame2[ICMP_CHKSUM_OFS] = 0;               // initialize checksum field
CopyFromFrame_EthMAC(&TxFrame2[ICMP_DATA_OFS], ICMPDataCount);        //    get data to echo...
*(unsigned short *)&TxFrame2[ICMP_CHKSUM_OFS] =   CalcChecksum(&TxFrame2[IP_DATA_OFS], ICMPDataCount + ICMP_HEADER_SIZE, 0);

this piece of code is duplicated below. Thus, all these stuff executed twice and cause wrong reply. Found in lpc1768_xpr_bb_110111 and lpc1768_xpr_bb_110721 (and probably in all other versions). In original example from RDB1768cmsis2 and RDB1768cmsis all is OK. Actually, by diffing these files I found the bug.

I've sent this to Embedded Artists some time ago and it looks like they have corrected this in new version of the example.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Sat Nov 26 17:17:13 MST 2011
[INDENT]

Quote:
Check it out: udpip.zip

Nice work, I like it. Just a few kB needed to receive and transmit UDP frames :)
[/INDENT][INDENT]Could you please add a simple project to show how a simple string can be transmitted and received ?

I fear a lot of members are a little bit overchallenged with things like callback functions :eek: and therefore can't use your lib
(and I don't want to post a project in order to avoid adorning myself with your work) :rolleyes:
[/INDENT]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by rattus on Wed Aug 17 20:20:57 MST 2011
[deleted - moved to new thread]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ajabo on Wed Aug 17 01:56:46 MST 2011

Quote: CodeRedSupport
This EMAC code has been tested with both PHYs (it was originally written for our RDB1768 board which exists in two versions - with the change in PHY being one of the differences).

However it is possible that there could be an issue here that only shows up with particular network setups. Could you attach your modified version of the code to this thread ?

Regards,
CodeRedSupport

I have rearranged and combined code from tcpip.c and ethmac.c, stripped the TCP (performance issue) and added UDP, eliminated the extra buffers (now building packets directly into assigned EMAC buffers to save one memcpy for every transmission) and got my own udpip.c/h, in which the difference in initializing the PHY's can be seen in initDP83848C() and initLAN8720() both called from within udpipInit() once the phyid is determined.
When running this in a looping foreground (and not accessing slow stuff like polling I2C transfers) I can get a response to a UDP message in 0.3 ms (verified using WireShark), so that is pretty good. Throughput is also pretty good, managing easily to receive 320kilobytes of data per second from the little LPCXPRESSO.

Check it out: [ATTACH]533[/ATTACH]

Aart

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Wed Aug 17 00:52:45 MST 2011
This EMAC code has been tested with both PHYs (it was originally written for our RDB1768 board which exists in two versions - with the change in PHY being one of the differences).

However it is possible that there could be an issue here that only shows up with particular network setups. Could you attach your modified version of the code to this thread ?

Regards,
CodeRedSupport

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ajabo on Wed Aug 17 00:17:17 MST 2011

Quote: Rob65
There are different examples: there is an EMAC example (called EMAC) which is for the MBC1700 board and that code indeed only supports the DP83848.
The easyweb from the lpcXpresso 4.0.5 folder LPCXpresso176x_cmsis2.zip supports the 8720

Rob

I was using CMSISv1p30 that came with my LPCXPRESSO 3.6.3, which also already supports the LAN8720. But just to make sure we are all on the same level I installed the latest 4.06 to check for changes in that support.
It turns out that nothing has changed there regarding the ethernet and easyweb, so I can safely say that when 'they' added support for the LAN8720 on top of the support for the DP83848C, 'they' made a little mistake. This mistake is the assumption that the status information for the connection (10MB/100MB Full/Half Duplex) could be read from the same PHY register (0x10) for both transceivers. However for the LAN8720 that information should be read from PHY register 31 (other bit positions too).
Because of this mistake a connection will be setup to 10MB by the LAN8720, but the EMAC is told it is 100MB and therefore tranmissions will fail.:(
Needless to say that after I changed the ethmac code, my board (EaBaseBoard btw) connected and communicated at 10MB and 100MB speed.:)

Aart

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Rob65 on Tue Aug 16 04:13:46 MST 2011

Quote: ajabo

In the mean time I found out that some of the code for the EMAC was faulty, since it was a rewrite from code for a version not using the LAN8720 transceiver (but the DP83848C).

Quote: Zero

Which easyweb are we talking about, V4.0.5 example folder ?

There are different examples: there is an EMAC example (called EMAC) which is for the MBC1700 board and that code indeed only supports the DP83848.
The easyweb from the lpcXpresso 4.0.5 folder LPCXpresso176x_cmsis2.zip supports the 8720

Rob

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ajabo on Tue Aug 16 02:50:33 MST 2011
I have had some trouble with it too and it turned out for me that the demo would not work on a 10MB ethernet connection.
Connection through a 100MB switch made it work.
In the mean time I found out that some of the code for the EMAC was faulty, since it was a rewrite from code for a version not using the LAN8720 transceiver (but the DP83848C).

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Ex-Zero on Mon Aug 01 00:23:04 MST 2011
Which easyweb are we talking about, V4.0.5 example folder ?