I am using the RM57 EMAC in a safety critical application and we want to avoid interrupt driven I/O. As such, the code is watching for EOQ flags on the CPPI descriptors to identify the state of the CPPI state machine. What appears to be happening is that the CPPI state machine is not updating the EOQ flag until the frame has completed transmission, but has internally already decided to stop processing.
Troubleshooting story:
The implementation always appends new descriptors to the active CPPI chain's tail. It then checks the status of the tail's EOQ to determine if the state machine needs HDP to be set. Intermittently, the CPPI chain stalls, showing an EOQ in an earlier descriptor, and never changing the OWNER flag of later descriptors. This happens on both the receive and transmit CPPI chains.
As a workaround, I am monitoring the HDP value, and when it has a value of 0, I'm restarting the chain using the CP->next. Does this seem like a sensible/safe approach?
Alternatively, I had another workaround (Workaround for RM57 EMAC EOQ race condition). But I never received a definitive answer as to the soundness of that approach.
As this is a safety critical application, I'd like to understand what TI recommends for operation of the EMAC.
