TMS570LC4357: EMAC decides to STOP well before it sets the EOQ.

I've designed a test harness around the EMAC itself to identify the lifecycle of the EOQ flag.  Here are my findings:

1. The OWNER and EOQ bits are set only at the completion of the last transfer just when the EMAC has STOPPED.

2. The EMAC decides at the beginning of the transfer whether it will STOP after the current transfer (i.e. it does not recheck the descriptor's next upon completion of the transfer).

When I looked at the LwIP Halcogen implementation, rather than chaining onto an active transfer, the driver waits until the previous transfer chain completes (i.e. polls for EOQ).  The need for this workaround matches the findings above.  Unfortunately, the wait duration can be significant and will not work in our real time designs.

/* Wait for the EOQ bit is set */
/*SAFETYMCUSW 28 D MR:NA <APPROVED> "Hardware status bit read check" */
/*SAFETYMCUSW 134 S MR:12.2 <APPROVED> "LDRA Tool issue" */
/*SAFETYMCUSW 45 D MR:21.1 <APPROVED> "Valid non NULL input parameters are assigned in this driver" */
while (EMAC_BUF_DESC_EOQ != (EMACSwizzleData(curr_bd->flags_pktlen) & EMAC_BUF_DESC_EOQ))
{
}

Per my findings above, its my belief the earliest point one can detect if the EMAC has STOPPED is right after a transfer completes using interrupts.  The ISR can then restart the chain if it detects that the EMAC has decided to STOP.

My question is:

Do my findings above characterize how the hardware is expected to behave?

* Technical Reference Exert

The discussion of the race condition does not identify that all previous transfers must be completed before checking for EOQ.  The discussion does identify that attaching to an active chain should be possible- but in practice, I find that this only works if I chain to an inactive chain and restart the EMAC once EOQ has been detected.