STMicroelectronics / STM32CubeF4

STM32Cube MCU Full Package for the STM32F4 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))
Other
827 stars 409 forks source link

USB_CoreReset(...) not waiting till reset is complete #85

Closed DanielKirsch closed 2 years ago

DanielKirsch commented 2 years ago

Describe the set-up

Describe the bug My original bug was that I got SCSI_ASC_NOT_READY_TO_READY_CHANGE ("USB Disk is not ready!") error in the communication by updating from v1.26.0 to 1.26.2! By analyzing the problem I found that the root cause came from removing the HAL_Delay(200U) in the function USB_HostInit(..). But because a delay doesn't seems to be useful at this point I searched were it's coming from and found the function USB_CoreReset(...).

USB_CoreReset(...) is setting the bit USB_OTG_GRSTCTL_CSRST in GRSTCTL and then checks if this bit is set. But by looking in the documentation the software has to wait that bit is cleared and not set! So the opposite was done here.

From my point of view this bug is critical and should be fixed as fast as possible.

Solution Replace in USB_CoreReset(...) the line } while ((USBx->GRSTCTL & USB_OTG_GRSTCTL_CSRST) == USB_OTG_GRSTCTL_CSRST); with } while ((USBx->GRSTCTL & USB_OTG_GRSTCTL_CSRST) == 0U);

DanielKirsch commented 2 years ago

Sorry I was to fast with my first analyzation. The while check is correct like it is. The funny part is that it was working with the opposite. My solution now is to add a HAL_Delay(50U) (50ms) after the while. At least 20ms are needed to get it working.

RKOUSTM commented 2 years ago

Hi @DanielKirsch,

Thank your for your reports. As this issue is related to user case and not directly related to the firmware published in this repository, please allow me to close this issue now.

Thank you again for your report. Feel free to reach out if you have additional questions. We are looking forward to reading from you again.

With regards,

DanielKirsch commented 2 years ago

As this issue is related to user case and not directly related to the firmware published in this repository, please allow me to close this issue now.

I don't think that I use the lib in a special way. And by the way it was working fine in the version before! There was a delay that was removed in the new version.

In the documentation dm00119316 is written:

Once this bit has been cleared, the software must wait at least 3 PHY clocks before accessing the PHY domain (synchronization delay). The software must also check that bit 31 in this register is set to 1 (AHB Master is Idle) before starting any operation.

The function USB_CoreReset(...) is not doing it, so why is it only waiting for the USB_OTG_GRSTCTL_CSRST bit and for the phy clocks and idle bit?

ALABSTM commented 2 years ago

Hi @DanielKirsch,

We asked our development teams again and they confirmed the issue you described cannot be related to the USB_CoreReset() function.

Indeed, from the description above, the issue seems to occur during enumeration phase while the USB_CoreReset() function is called during initialization phase, which occurs before.

I hope this gives you a helpful hint for you analysis in case you still face the same issue.

With regards,