Honored Contributor
Honored ContributorThank you for your answers Bill.
I definitely think it's a driver or cache problem as you suggested. If you have any other advice I'll be grateful, since I've been stuck on this point for a few days so far. This is my latest results: I'd exclude hw/fpga problems: I reduced Nios frequency,removed data cache,changed Quartus project fitting effort, timing constraints and clock distribution system but I always obtained exactly the same behaviour. I kept on testing with the problematic case: rx frame arriving 15us after sending the tx frame (both 60 bytes long, about 6us required for transmission) - tx frame period = 5ms: frames correctly transmitted for 510ms, then it doesn't work for 330ms, then again ok for 510ms and so on - tx frame period = 10ms: similar behaviour but ok/bad times are splitted 650/190 - tx frame period >= 25ms: ok Note that the period is always 840ms: why? Can this suggest the cause of the problem? Finally: remind that if tx and rx frames are almost overlapped on wire (<5us skew) or are very separated (>50us) the system works perfectly, whatever the frame rate is!!! Regarding the phy driver, I use Quartus 9.0sp2 and this actually supports only National DP83865 and DP83848C. My dev board came with a patch of altera_avalon_tse.c in order to support the DP83640 phy. I'll check this file for bugs Regards Cris
