Delay functions in STM32F4 USB Peripheral Library and USB-Unknown device issues

[pradeepa]

Posted on June 22, 2015 at 07:45

Hello,

We are using STM32F415RG76 chip in one of our products and we are facing a very confusing USB issue. The issue comes when we switch the microcontroller from the bootloader to application-firmware.In some of the USB controllers, when we switch from bootloader to application-firmware we get Unknown Device issue. We analyzed the Unknown Device issue and we are certain that it is not caused by any driver. We believe that this happens due to some timing issue. We properly reset interrupts, vector tables, etc. when we do the switching. At the moment we see this issue only in ''

Intel� 6 Series/C200 Series Chipset Family USB Enhance Host Controller''s.

That makes it even harder to debug.

When we check the USB Library provided by ST we found out few delay functions, Namely,USB_OTG_BSP_mDelayUSB_OTG_BSP_uDelayBut both these functions are internally using while loops to generate delays, which as we know depends on the core clock. We noticed that when we change the SYSCLK to 168 MHz the Unknown Device issue does not come but if we use 72 MHz clock the Unknown Device issue comes. But still we are not sure that the root cause for the issue is the way that delay functions were implemented. We would like to know your opinion on this issue? We are still investigating and we'll be posting our findings here as well.Important:Please note that this issue does not come always and does not come in every USB controller. Which is why it is very hard to debug. But we are certain that there are PCs which gives this issue which makes our product not usable to them unless we fix it. Thank you. #clive1 #clive1 #stm32f4-usb

[Tesla DeLorean]

Posted on June 22, 2015 at 14:22

So debug it on the hardware it fails on, use a USB Analyzer to understand what's going on over the bus. You could also instrument the STM32 side to understand how that's reacting, and the general flow of things.

Yes, I've noticed that some of the TIM based delays assume 72 MHz, this comes from the STM32F1 heritage. You'd need to evaluate the purpose (underlying) of the delays, and how to translate that to 84/168 MHz clocking schemes.

[pradeepa]

Posted on June 23, 2015 at 06:10

Hello Clive1,

Thank you for your answer. We found out and fixed the issue yesterday. Now it's working. It's a mistake we did at our side, not a fault in your side. But if the documentation is slightly improved that could be very useful. For anyone who might have faced this issue the following fix could work.There is a file in the USB library ''usb_bsp.c'' and the functions inside that file should be ported according to the application. Hence the name bsp (Board Specific Package). This file contains a function called ''USB_OTG_BSP_uDelay'' which is used to generate delays in the USB core. (But in contrast to what clive1 mentioned, I could not find any delay in USB-Library which depends on TIM, all were while loops (busy waits)) Unfortunately the USB_OTG_BSP_uDelay function assumes the clock frequency to be 168 MHz. Therefore we have to adjust the delay to make it compatible with our custom clock. We used the following code in that function,void USB_OTG_BSP_uDelay (const uint32_t usec){  uint32_t count = 0;  uint32_t utime = 0;      /* PS:      Here we should make sure that we adjust the delay function   to generate correct delay based on the used clock freq.      */  double factor = (double)(168000000.0 / (double)SystemCoreClock);  utime = ((double)(120.0 / factor) * (double)((double)usec / 7.0));    do  {    if ( ++count > utime )    {      return ;    }  }  while (1);}Now the delay function will get adjusted based on the clock. Now everything works fine.Please note that this issue only comes with certain USB controllers.I hope it helps.Thank you.