Hi All
I looked into the problem again today and identified that it wasn't a
reception loss problem but (seemingly) a transmission loss. When TCP windowing
is used to send several frames quickly (eg in images) some were not being sent
and had to be repeated.
There is the following routine (used in the LPC23XX project but seemingly never
actually detected a clocked transmitter:
// This can be called by the Ethernet driver to wait a short time for the
transmit buffer to become free
//
extern int fnWaitTxFree(void)
{
volatile int iMaxWait = 1500;
unsigned long ulConsumeCheck;
unsigned long ulConsumeIndex = EMAC_TxConsumeIndex; // snap
shot of consume index
if (ulConsumeIndex == 0) {
ulConsumeCheck = EMAC_TxDescriptorNumber;
}
else {
ulConsumeCheck = (ulConsumeIndex - 1);
}
if (EMAC_TxProduceIndex == ulConsumeCheck) {
while (EMAC_TxConsumeIndex == ulConsumeIndex) {
if (!(--iMaxWait)) {
return 1; //
abort because we have waited too long
}
}
}
return 0; // OK -
buffer free
}
So I increased the wait from 1500 to 20000 and all 'standard' pages
with images then worked >95%.
Still not perfect but certainly (measurably) better.
Looks like some more study since there is a definite difference between the
chips, but why the Ethernet is causing such problems is not at all obvious.
Regards
Mark
LPC24xx Ethernet (errata, reliability, compatibility to LPC23xx)
Started by ●June 20, 2009