AnsweredAssumed Answered

STM32_USB-FS-Device_Lib_V4.1.0  :  not sure if this is a bug in usb_core.c

Question asked by uz slm on Oct 17, 2017

STM32_USB-FS-Device_Lib_V4.1.0

file                  :usb_core.c

funciton name:  RESULT Standard_ClearFeature(void)

code               :

  if (wIndex0 & 0x80)
{
/* IN endpoint */
if (_GetTxStallStatus(Related_Endpoint ))
{
ClearDTOG_TX(Related_Endpoint);
SetEPTxStatus(Related_Endpoint, EP_TX_VALID);
}
}
else
{
/* OUT endpoint */
if (_GetRxStallStatus(Related_Endpoint))
{
if (Related_Endpoint == ENDP0)
{
/* After clear the STALL, enable the default endpoint receiver */
SetEPRxCount(Related_Endpoint, Device_Property.MaxPacketSize);
_SetEPRxStatus(Related_Endpoint, EP_RX_VALID);
}
else
{
ClearDTOG_RX(Related_Endpoint);
_SetEPRxStatus(Related_Endpoint, EP_RX_VALID);
}
}
}

question: i saw that status of IN endpint was set to VALID(EP_TX_VALID) after recover from HALT;

                i wonder why we don't set the status to NAK;

                The USB spec doesn't specify how to leave the endpoints after a halt is cleared.

                but for an interrupt IN endpoint such as a HID device,at that point when the endpoint recover from halt status,the device will send an  packet with uncertain data to the host,since the host automatically query the device  by IN token in a determined interval constantly,and it can be quite possible for the packet buffer contains uncertain data at that point;

                possible advice: just set the status to NAK,firmware could set it to VALID if necessary data get ready to transfer to host later.

 

Regards,

uzslm

Outcomes