Hello Steve, thank you for your detailed information and hints.
We extended the given loopbacktest of the BSL with random pattern and frame size and used it over multiple cylces. The results are ok, so the driver code is working well with the EMAC loopback.
In our real project (using the PHY with physically Rx frames) and when looking into details of the corrupted Rx frames, I see, that frame content is only partially overwritten, when a second frame is received in a buffer, that has already been used. Right now, we are investigating for possible causes. If you have any hint concerning this detail, it would help us.
The EMAC and the driver use a kind of ring buffering in a descriptor chain. What I do not understand is, why the EMAC needs a 'EndOfQueue' (EOQ) signal, because it already uses the 'Owner' Flag, which prevents from using buffer descriptors, which are still in use (not yet read) by the application.
The second item I was astonished about, is, that in the driver code the Rx descriptor queue is 'rotated' after a frame was read. Changes in the descriptor queue at runtime are not recommended in TIs 'EMAC user Guide' (
http://focus.tij.co.jp/jp...rufu9a/sprufu9a.pdf) But as our extended loopback test works well, this should not be the reason for our issue.
> exercising the emac would be TI's linux distribution.
Thank you for those links. I already took a glance into it, but the driver there is completely different and much more than we need. But we will check that too.
So, thank you very much so far for your support!
Ralf