Temac, XMD, "rx packet rejected" Spartan 3E

[jprovidenza]

I'm using the Temac on a Spratan 3E with lwIP  and am seeing an odd problem when I download and run

my test program. 

If I download using XMD and immediately type Run, the software usually starts upOK and I get an IP address

via DHCP correctly.

If I download and wait a couple of minutes, then type Run, I frequently get an "rx packet rejected" message

and DHCP fails.  This is pretty consistent.

I'm forced to use the 9.2 generation of software for several reasons at this point.

Any thoughts or suggestions?

Thanks!

John P

[dylan]

Is there any build/temp dependence to this issue?  There was some improvements in temac stability in EDK 11.1+ that fixed issues like this.  I'd suggest 11.4 for debugging purposes.

[jprovidenza]

No, this happens with the system at a reasonable temperature. 

We can't change to ISE/EDK 11.x at this point, we're stuck with 9.2

This is happening with a 100 Mbit connection, so I don't think there are

timing/temp issues.

John P

[dylan]

What I meant was does the error rate change based on temperature.  Or if you create a build with slightly different map options, or a slightly different MHS, do some bit files work better?

[jprovidenza]

The issue is not really an error rate - I get the error message during the boot up process

and after that the system is dead.  I suspect the error kill part of the DHCP process,

but I need to dif deeper to see what goes dead after the rx error appears.

I'm just currious as to

  a) if other people have seen/solved this

  b) why on earth this is related to the delay in typing "run" to the debugger.

John P

[dylan]

Since you said you are letting the design warm up to cause failures, it sounds like a timing problem to me.  Some asynchronous/latch issues were addressed in the 11.1+ temac, from the changelog:

[<CR472683><CR471362><CR476763>] 11.1 EDK - xps_ll_temac_v2_00_a, Removed all asynchronous resets and all latches

 I am somewhat confident that this is the issue you are running into. 

If you want, you can try to set this in your UCF to band-aid the issue:

ENABLE=reg_sr_r;

which should improve the stability, if you can meet timing with it enabled.

[jprovidenza]

I can try this, but I believe it's barking up the wrong tree.

With the system at a stable temperature, I can download the test program

with XMD, hit run right away, and the system works.  I can immediately

re-download the test program, wait a couple of minutes, type run, and it fails.

I can repeat this over and over and I see the same type of failure.  I just don't

think temperature is the root cause.

John