2019-10-11 04:28 AM
I'm using an STM32L496 on a custom board and using USB CDC configured through CubeMX (STM32Cube FW_L4 V1.14.0). This connects to a Windows 10 laptop. Randomly I get "USB device not recognised". I can go days without the issue and then it suddenly appears and will fail 20+ times in a row and then be OK once or twice and then fail again. When it fails, Device Manager shows "A request for the USB BOS descriptor failed".
I've increased the heap size as per https://community.st.com/s/article/FAQ-USB-device-not-recognized but still get the issue. My usbd_conf.h has the line "#define USBD_malloc (uint32_t *)USBD_static_malloc" so I believe I'm using static allocation.
Grateful for any help.
2019-10-25 05:19 AM
Paul,
your question falls into the broad cathegory of "I used a "library" (usually through clicking in CubeMX) for one of the more complex peripherals, and it fails in some way".
Yes, there are very rarely known bugs; but in the vast majority of cases, it's up to you to debug it just as with any other application. And, as USB indeed belongs to the "more complex peripherals", debugging it means nothing but blood, toil, tears and sweat. Especially if the problem is intermittent even sporadic.
So, what's the point of answering you with "oh cm'n get your bus analyzer and sit down to a serious debugging session"?
JW
2019-10-25 07:52 AM
Hi Jan,
I take your point however sometimes you get lucky and someone else has already encountered exactly the same problem and has a fix for it :) If I find the fix I'll post it here.
Paul
2019-10-25 07:53 AM
https://community.st.com/s/feed/0D50X0000BWomNp
2019-10-25 11:30 AM
-- pa
2019-11-04 07:02 AM
Thanks for all the responses to this.
Adding some more detail and the fix (I hope). I tried different laptops, cables etc. but it made no difference. I think the problem got worse after upgrading to STM32Cube FW_L4 V1.14.0. The USB host correctly read the device descriptor but failed to get the configuration descriptor. In the end I built a fresh project from scratch just implementing a USB CDC interface and found that it worked perfectly on my custom board. I tracked down the differences between this project and my current one and these are the ones that seem to have fixed the problem for me (changes were made in CubeMX > Clock Configuation):
- SYSCLK/HCLK changed from 16MHz to 32MHz
- APB1 Prescaler changed from /2 to /4
- APB2 Prescaler changed from /1 to /2
- Cortex System timer/FCLK Cortex clock/APB2 Timer clocks changed from 16MHz to 32MHz
BTW I'm using a crystal-less USB clock (HSI48) with CRS enabled. Hope this helps anyone else with a similar issue.
Cheers,
Paul
2019-11-04 12:40 PM
Paul,
Thanks for coming back with your findings.
I wonder, what exactly was the underlying mechanism.
The OTG chapter requires HCLK be at least 14.2MHz, without any explanation; maybe that value is wrong or marginal. There's also a parameter, TRDT, which depends on HCLK, I wonder if that was set correctly - and if the table in RM according to which it is set, is correct at all.
However, if upgrading CubeL4 without changes in the clocks did make difference, too, it might indicate also some critical path in the software.
JW
2019-11-15 12:44 PM
Hi Jan,
I have a further update. The issue seems to be fixed on my home laptop but not on my work laptop where it correlates almost exactly with the twice daily virus scan (CPU running at >30%) that my company insists on doing!
Paul
2019-11-17 06:41 AM
Strange. I thought your problem happens only when you connect the device - do you disconnect/connect it during the virus scan?
It would be nice to find out if the problem is related to
crystal-less USB clock (HSI48) with CRS enabled
by connecting a crystal (even if just in some "bird nest" improvized fashion).
JW
2019-11-28 01:24 AM
I'm often restarting (or connecting/disconnecting USB) the STM32 to test out new features ... and there's often a virus scan running in the background. Just tried with an 8MHz crystal on HSE and the problem is still there. At the moment I can live with it, I just do my debugging outside of the virus scans!
Paul