fjpanag commented on PR #8566: URL: https://github.com/apache/nuttx/pull/8566#issuecomment-1435265890
Oh. there is also erratum 2.17.6, again suggesting the use of store-and-forward: > **2.17.6 - Incorrect status and corrupted frames when RxFIFO overflow occurs** > **on the penultimate word of Rx frames** > > **Description** > When operating in Threshold mode, the RxFIFO may overflow when the received frame > data is written faster than the speed at which the application reads it from the RxFIFO. The > RxFIFO overflow is declared at the moment that a non-EOF word is received and the > RxFIFO has only two locations available. The receiver descriptor overflow error (OE) bit of > the RDES0 receive descriptor word0 is set to indicate that the receive fram e is incomplete. > The problem occurs after the following events: > 1. RxFIFO overflow is declared exactly on the penultimate word of the Rx Frame. The > EOF word is received in the next clock cycle. > 2. The EOF word has exactly one valid byte. This is possible only when the length of the > packet, after CRC or PAD stripping (if enabled), is a multiple of 4 bytes plus 1 (for > example, 5, 9, 13, 17). > After the above sequence, the frames status information is corrupted and the overflow error > flag is not set. > Furthermore, if the next frame arrives soon enough, the MAC might falsely interpret that > there is space in the RxFIFO and overwrite unread data with the next frame, thus corrupting > the existing frames. > The MAC recovers automatically after transferring a few corrupt or incorrect packets. > > **Workaround** > Operate the RxFIFO in the Store-and-Forward mode. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
