You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This pertains to section 8.5.3.3 Error Handling on the Last Data Transaction
Consider a Control write where the ACK of the last data OUT transaction goes missing en route to the host.
The xCORE will typically move on to the status stage, the host will retry the last data OUT. This will lead to the xCORE Nacking the host indefinitely. The xCORE need's to continue to accept the OUT's until the data stage is started.
Now consider a Control read where the last data IN transaction is lost from host -> device. The device will wait for another IN and an attempt to re-send. The host will attempt to move on to the status stage. The xCORE will typically Nak this indefinitely
as it waits for the retry on the IN. The xCORE needs to move on when the status stage is started.
Along with #341 this further identifies the need to more coarsely encapsulate control transfers. Essentially the XUD API provides too much granularity in this area allowing developers to shoot themselves in the foot and create out of spec devices.
Ultimately this is handling of rare error cases and should be prioritised accordingly.
The text was updated successfully, but these errors were encountered:
This pertains to section 8.5.3.3 Error Handling on the Last Data Transaction
Consider a Control write where the ACK of the last data OUT transaction goes missing en route to the host.
The xCORE will typically move on to the status stage, the host will retry the last data OUT. This will lead to the xCORE Nacking the host indefinitely. The xCORE need's to continue to accept the OUT's until the data stage is started.
Now consider a Control read where the last data IN transaction is lost from host -> device. The device will wait for another IN and an attempt to re-send. The host will attempt to move on to the status stage. The xCORE will typically Nak this indefinitely
as it waits for the retry on the IN. The xCORE needs to move on when the status stage is started.
Along with #341 this further identifies the need to more coarsely encapsulate control transfers. Essentially the XUD API provides too much granularity in this area allowing developers to shoot themselves in the foot and create out of spec devices.
Ultimately this is handling of rare error cases and should be prioritised accordingly.
The text was updated successfully, but these errors were encountered: