Thank you Markus, thank you Bostjan.
I will check that as soon as I have got a full IDE.
Your remarks are very valuable for me.
Thank you very much!!!

Henry

--- In l..., Markus Zingg wrote:
>
> This is documented in the errata, and it's dependant on the chip
> version. I use the following code to make it work independant of the
> chip version:
>
> /* Note, there is a bug with older LPC23xx chips which require to
set
> P1.6
> (ENET-TX_CLK) or not depending on the version of the EMAC
module. We
> therfore test here against this version and act acordingly. */
> regVal = MAC_MODULEID;
> if( regVal == NXP_OLD_MAC_MODULE_ID )
> PINSEL2 = 0x50151105; /* selects P1[0,1,4,6,8,9,10,14,15] */
> else
> PINSEL2 = 0x50150105; /* selects P1[0,1,4,8,9,10,14,15] */
>
> MAC_MODULEID is defined like this:
>
> #define MAC_MODULEID (*(volatile unsigned long
*)(MAC_BASE_ADDR +
> 0xFFC)) /* Module ID reg (RO) */
>
> and NXP_OLD_MAC_MODULE_ID is defined like this:
>
> #define NXP_OLD_MAC_MODULE_ID (UINT32) ((0x3902 << 16) | 0x2000)
>
> HTH
>
> Markus
>
> Glazar, Bostjan schrieb:
> >
> > I had the same experience.
> >
> > However, I have only needed EMAC driver. I took the driver from
> > lwIpWep.zip and used it with my existing project.
> > I couldn't find my post with a bug, therefore I'm posting part of it
> > below again.
> > There is a hardware bug associated with this that is described in the
> > LPC Errata. There is also algorithm for the code to detect chip
> > revision and use the correct EMAC initialisation.
> >
> > Sorry for late answer... I was on vacation.
> >
> > When initing EMAC reserved bits in PINSEL registers should not be
> > written 1. When this is the case the CPU crashed on EMAC init. I did
> > not know this and thought that the requirement of not writing ones is
> > for forward compatibility only.
> > In the function Init_EMAC() there is:
> > PINSEL2 = 0x55555555;
> > It should be:
> > PINSEL2 = 0x50150105;
> >
> > > I downloaded lwIpWep.zip and loaded lwIpWeb.hex to the MCB2300
board.
> > > There was that text on the LCD display but Firefox did not show any
> > > result.
> > > I then adapted the IP address to my LAN and loaded the file
again - no
> > > improvement.
> >
> >
> >
>

This is documented in the errata, and it's dependant on the chip
version. I use the following code to make it work independant of the
chip version:

/* Note, there is a bug with older LPC23xx chips which require to set
P1.6
(ENET-TX_CLK) or not depending on the version of the EMAC module. We
therfore test here against this version and act acordingly. */
regVal = MAC_MODULEID;
if( regVal == NXP_OLD_MAC_MODULE_ID )
PINSEL2 = 0x50151105; /* selects P1[0,1,4,6,8,9,10,14,15] */
else
PINSEL2 = 0x50150105; /* selects P1[0,1,4,8,9,10,14,15] */

MAC_MODULEID is defined like this:

#define MAC_MODULEID (*(volatile unsigned long *)(MAC_BASE_ADDR +
0xFFC)) /* Module ID reg (RO) */

and NXP_OLD_MAC_MODULE_ID is defined like this:

#define NXP_OLD_MAC_MODULE_ID (UINT32) ((0x3902 << 16) | 0x2000)

HTH

Markus

Glazar, Bostjan schrieb:
>
> I had the same experience.
>
> However, I have only needed EMAC driver. I took the driver from
> lwIpWep.zip and used it with my existing project.
> I couldn't find my post with a bug, therefore I'm posting part of it
> below again.
> There is a hardware bug associated with this that is described in the
> LPC Errata. There is also algorithm for the code to detect chip
> revision and use the correct EMAC initialisation.
>
> Sorry for late answer... I was on vacation.
>
> When initing EMAC reserved bits in PINSEL registers should not be
> written 1. When this is the case the CPU crashed on EMAC init. I did
> not know this and thought that the requirement of not writing ones is
> for forward compatibility only.
> In the function Init_EMAC() there is:
> PINSEL2 = 0x55555555;
> It should be:
> PINSEL2 = 0x50150105;
>
> > I downloaded lwIpWep.zip and loaded lwIpWeb.hex to the MCB2300 board.
> > There was that text on the LCD display but Firefox did not show any
> > result.
> > I then adapted the IP address to my LAN and loaded the file again - no
> > improvement.
>
>
>
>

I had the same experience.

However, I have only needed EMAC driver. I took the driver from lwIpWep.zip and used it with my existing project.
I couldn't find my post with a bug, therefore I'm posting part of it below again.
There is a hardware bug associated with this that is described in the LPC Errata. There is also algorithm for the code to detect chip revision and use the correct EMAC initialisation.

Sorry for late answer... I was on vacation.

When initing EMAC reserved bits in PINSEL registers should not be written 1. When this is the case the CPU crashed on EMAC init. I did not know this and thought that the requirement of not writing ones is for forward compatibility only.
In the function Init_EMAC() there is:
PINSEL2 = 0x55555555;
It should be:
PINSEL2 = 0x50150105;

> I downloaded lwIpWep.zip and loaded lwIpWeb.hex to the MCB2300 board.
> There was that text on the LCD display but Firefox did not show any
> result.
> I then adapted the IP address to my LAN and loaded the file again - no
> improvement.

Hi,

I downloaded lwIpWep.zip and loaded lwIpWeb.hex to the MCB2300 board.
There was that text on the LCD display but Firefox did not show any
result.
I then adapted the IP address to my LAN and loaded the file again - no
improvement.

Also I did not find that ethernet driver for LPC MAC in the files section.
Bostjan, Could you please advice on the bugs that have to be
corrected? Perhaps you can give me a message id or the subject string
if that issue has been discussed before.

Regards,
Henry
--- In l..., "Glazar, Bostjan"
wrote:
>
> I'm using lwIP stack from Adam Dunkels with LPC2368 and LPC2214. He
has also written smaller stack uIP. The later has window of only one
packet and therefore requires much less RAM and code. Ethernet driver
for LPC MAC can be found at this forum as it was already written
(correct those bugs before using!).
>
> Just send and receive function will not be enough, since you need to
ACK data received and retransmit undelilevered data (TCP transport).
You also need timer and MAC interrupt functions.
>
> However with UDP things are simpler, at least from stack point of view.
>
>

--- In l..., "h.belig" wrote:
>
> Hello,
>
> I am using a Keil MCB2300 evaluation board with LPC2378 and Keil's
> Vision3 IDE (evaluation).
> I want to send blocks of data via TCP/IP to another computer and vice
> versa receive data from that other computer.
> Just this, nothing else (regarding ethernet).
>
Hi

Take a look at http://www.uTasker.com (or the LPC forum at
http://www.uTasker.com/forum/)

Regards

Mark

If using 'raw' communication over Ethernet, you can just add fixed IP and UDP headers to the datapacket and you have a TCP/IP compliant communication. Message length and CRC are also included in the headers.

Note: If you ommit ARP protocol, you should use arp command to bind IP to MAC.

Re: TCP/IP send and receive with LPC2378

Hello,
I had a look at the errata sheet at
http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/errata.lpc\
2378.pdf.
According to that sheet the bug only applies to silicon revision '-',
not to 'A' and 'B'.
If you noticed that bug with revision 'A' or 'B', please let us know!

Henry

--- In l..., "per_martin_l" wrote:
>
> Hallo
> Just thought i would mention that there are hardware bugs in LPC2378....
> If this is not compensated for the JTAG will be shut down
> and need to be reactivated by a download through the seriel line.
>
> regv = MAC_MODULEID;
> if(regv == OLD_EMAC_MODULE_ID) /* Correct a hardware bug in the
> mac module according to . */
> {
> PINSEL2 |= 0x50151105;
> }
> else
> {
> PINSEL2 |= 0x50150105;
> }
>
> I used "RAW" ethernet frames for communication and it works fine.
> "Propriaty software though...."
> Make sure to put the speed right, or use auto negotiation on one side
> only.(This is a lot slower.)
> Not also that the shortes frame is 64 Byte.Regardless of how many
> bytes you want to transfer.So you might want to include a length field
> when using "Raw" frames.
> Using "WIRE SHARK" program is highly recomended!!!
>
> Good luck.
>
> Regards
> /Martin
>
> --- In l..., "Glazar, Bostjan"
> wrote:
> >
> > I'm using lwIP stack from Adam Dunkels with LPC2368 and LPC2214. He
> has also written smaller stack uIP. The later has window of only one
> packet and therefore requires much less RAM and code. Ethernet driver
> for LPC MAC can be found at this forum as it was already written
> (correct those bugs before using!).
> >
> > Just send and receive function will not be enough, since you need to
> ACK data received and retransmit undelilevered data (TCP transport).
> You also need timer and MAC interrupt functions.
> >
> > However with UDP things are simpler, at least from stack point of
view.
> >
> >
> >
>

Hello,
I had a look at the errata sheet at
http://www.standardics.nxp.com/support/documents/microcontrollers/pdf/errata.lpc2378.pdf.
According to that sheet the bug only applies to revision '-', not to
'A' and 'B'.
If you noticed that bug with revision 'A' or 'B', please let us know?

Henry

--- In l..., "per_martin_l" wrote:
>
> Hallo
> Just thought i would mention that there are hardware bugs in LPC2378....
> If this is not compensated for the JTAG will be shut down
> and need to be reactivated by a download through the seriel line.
>
> regv = MAC_MODULEID;
> if(regv == OLD_EMAC_MODULE_ID) /* Correct a hardware bug in the
> mac module according to . */
> {
> PINSEL2 |= 0x50151105;
> }
> else
> {
> PINSEL2 |= 0x50150105;
> }
>
> I used "RAW" ethernet frames for communication and it works fine.
> "Propriaty software though...."
> Make sure to put the speed right, or use auto negotiation on one side
> only.(This is a lot slower.)
> Not also that the shortes frame is 64 Byte.Regardless of how many
> bytes you want to transfer.So you might want to include a length field
> when using "Raw" frames.
> Using "WIRE SHARK" program is highly recomended!!!
>
> Good luck.
>
> Regards
> /Martin
>
> --- In l..., "Glazar, Bostjan"
> wrote:
> >
> > I'm using lwIP stack from Adam Dunkels with LPC2368 and LPC2214. He
> has also written smaller stack uIP. The later has window of only one
> packet and therefore requires much less RAM and code. Ethernet driver
> for LPC MAC can be found at this forum as it was already written
> (correct those bugs before using!).
> >
> > Just send and receive function will not be enough, since you need to
> ACK data received and retransmit undelilevered data (TCP transport).
> You also need timer and MAC interrupt functions.
> >
> > However with UDP things are simpler, at least from stack point of
view.
> >
> >
> >
>

Hallo
Just thought i would mention that there are hardware bugs in LPC2378....
If this is not compensated for the JTAG will be shut down
and need to be reactivated by a download through the seriel line.

regv = MAC_MODULEID;
if(regv == OLD_EMAC_MODULE_ID) /* Correct a hardware bug in the
mac module according to . */
{
PINSEL2 |= 0x50151105;
}
else
{
PINSEL2 |= 0x50150105;
}

I used "RAW" ethernet frames for communication and it works fine.
"Propriaty software though...."
Make sure to put the speed right, or use auto negotiation on one side
only.(This is a lot slower.)
Not also that the shortes frame is 64 Byte.Regardless of how many
bytes you want to transfer.So you might want to include a length field
when using "Raw" frames.
Using "WIRE SHARK" program is highly recomended!!!

Good luck.

Regards
/Martin

--- In l..., "Glazar, Bostjan"
wrote:
>
> I'm using lwIP stack from Adam Dunkels with LPC2368 and LPC2214. He
has also written smaller stack uIP. The later has window of only one
packet and therefore requires much less RAM and code. Ethernet driver
for LPC MAC can be found at this forum as it was already written
(correct those bugs before using!).
>
> Just send and receive function will not be enough, since you need to
ACK data received and retransmit undelilevered data (TCP transport).
You also need timer and MAC interrupt functions.
>
> However with UDP things are simpler, at least from stack point of view.
>
>

An Engineer's Guide to the LPC2100 Series