Skip to main content
shingadaddy
Senior
March 28, 2017
Solved

STM32L476 USB inconsistencies.

  • March 28, 2017
  • 65 replies
  • 8897 views
Posted on March 29, 2017 at 00:21

I've been working with USB on my Nucleo board(S)  for some time now. Been comfortably successful at getting a few operational interfaces working with it. Including DFU. STM32L476. So time to make our own PCBS! We knocked out an order for 10 . Production needing 7 and having a few SPARES to help wear off the new. Ran into a little problem and I turned in an online help request. Waited all day and thought maybe someone there might notice I marked it Critical. Not sure of the turnaround time but everybody's critical  might be a little different. Hope I hear and in the mean time here's where I got too.

We have 10 Brand new (Identical) PCB's with STM32L476VG's on them.

They use the direct connected USB for communication. (PA11/PA12)

They are *all* loaded with the same binary, VIA DFU.

DFU works. Dependably.

The binary is the STM32CubleL4 HAL DEMO from EVAL board, with IO EXPANDER commented out. This runs the LEDS on EVAL and is the only thing needed to be removed for this to work. I figure it works good as a TEST LOAD.

Operationally :

  7 Enumerate/seem to work.  ------  3 DO NOT even enumerate correctly.

Do not meaning: 2 -  with DEVICE NOT RECOGNIZED responses.  1 -  PC IGNORING COMPLETELY

I use VBUS DETECT. USB 5VDC is getting to PA9 on the one the is completely ignored.  

We have matched lines on the USB traces about .7 inches between the type C USB connector and the MICRO. Connectivity is direct via usb line suppressors (TI_SN65220DBVR). No inline resistors. No Pull up on D+.I am going to gather these up personally and look into it. But this is being tested by very capable individuals with years of experience and there does not seem to be a difference in the PCBS PHYSICALLY or SIGNAL WISE. The code that is running on them is the STM32CubeL4 USB in DEVICE MODE -CDC DEMO from the EVAL project in TrueStudio.

My immediate questions would be.

1. Suggestions such as the 'Oh yeah' type, as to what might be wrong?.

2. Since DFU mode works, (and 7 others) shouldn't the enumeration at least be functional on the operational testing?

3. Does DFU USE a different SPEED that is not as critical as USB FS.

4. Does the MSI trimmed with LSE, really provide precision/stability good enough for USB FS?

Crystal = Abracon ABS25-32.768KHZ-T

This is our first 10 in a production run and we are now a little nervous on the 70% operational aspect.

Power = CLEAN

OSC/Clock CLEAN

FDMOD set so FORCED DEVICE MODE is true.

Ground plane internally.

I had one nucleo dev board (Out of 5 or 6) that I used for a while until it acted like it had a heat sensitivity problem after some operational time. Then DEVICE NOT RECOGNIZED. On more than one computer. Unless I left it unplugged for about 30 minutes. Then BACK IN BUSINESS !   THAT is flakiness at its finest. And now I think - maybe we have more?

Just thought I'd drop this here too and see if anyone had any ideas. I really didn't think I had to get the LED out and chase it though the code (again) But here I am. Not amused at all.

Any input appreciated.

Thanks folks.

    This topic has been closed for replies.
    Best answer by waclawek.jan
    Posted on April 07, 2017 at 00:57

    Omit Fred, fix the bug I told about above (instead HSICalibrationValue should be MSICalibrationValue).

    JW

    65 replies

    shingadaddy
    Senior
    April 6, 2017
    Posted on April 07, 2017 at 01:38

    Sorry I have to head out and Support requested an overnight run with what they sent.

    It works too but just skips PLL's and runs sysclock off HSI (LIKE DFU)   Yeah that gets 48Mhz too.

    I'll fix the HSI / MSI cal line 204 tomorrow too!

    THANK you Jan!

    And THANK you ST !

    Jan Waclawek
    Visitor II
    April 7, 2017
    Posted on April 07, 2017 at 02:03

    Support requested an overnight run with what they sent.

    It works too but just skips PLL's and runs sysclock off HSI (LIKE DFU)

    Hasn't Bertrand said that DFU uses MSI?

    Humm.

    JW

    ST Employee
    April 7, 2017
    Posted on April 07, 2017 at 11:06

    I was refering  to the USB clock source, not the sysclock. But I'm still not sure what was the source of the issue. Sounds like a clock configuration problem.

    shingadaddy
    Senior
    April 7, 2017
    Posted on April 07, 2017 at 15:45

    It ran all night fne 48.007Mhz.

    Time for some cruelty testing.

    Skip PLL's = Skip the OTHER PLL's generating the 80Mhz.

    waclawek.jan
    Super User
    April 7, 2017
    Posted on April 07, 2017 at 15:51

    Okay so it uses an entirely different code to set up the clocks than the Cube snippet I quoted above, isn't it?

    Can you please try the original one with only the one letter HSI...-->MSI... fixed, perhaps on a different but also failing board?

    Thanks,

    Jan

    Amel NASRI
    ST Technical Moderator
    April 7, 2017
    Posted on April 07, 2017 at 16:30

    Can you please try the original one with only the one letter HSI...-->MSI... fixed, perhaps on a different but also failing board?

    +1

    To give better visibility on the answered topics, please click on "Best Answer" on the reply which solved your issue or answered your question.
    shingadaddy
    Senior
    April 7, 2017
    Posted on April 07, 2017 at 16:35

    Offered by Jan on the forum. Quite possibly the REAL cause all along. I'd vote with Jan . :)

    And it still warrants more attention from ST.

    Overnight test finished. Stable at 48 MHZ after tortured a bit.

    Original demo code loaded back in. Initially came up at 48Mhz(?)  Flakey....

    Unplug - Replug = 57Mhz.    Okay that's what I thought..

    Changing line 204 makes it happy.

    BAD WAS -  RCC_OscInitStruct.

    HSICalibrationValue

    = RCC_MSICALIBRATION_DEFAULT;

    GOOD IS -  RCC_OscInitStruct.

    MSICalibrationValue

    = RCC_MSICALIBRATION_DEFAULT;

    In the BAD configuration the

    MSICalibrationValue

    was left UNINITIALIZED because the initial STRUCT was UNINITIALIZED.

    Unplug - replug 10 times. No change = HAPPY   = 48Mhz

    My DELAY LINES fix, while just a crude TEST, were probably getting the stack/ram RANDOMLY loaded with accidental values that left the MSI trim values in a random HAPPY (48Mhz) state instead of NO delay lines leaving it in a random UNHAPPY (57Mhz) state. That's just my guess.

    I've notified my contact of this finding also. I'm going to press on but I'll probably init the entire struct also.

    Many thanks to Jan and ST for the helpful exchanges!

    Amel NASRI
    ST Technical Moderator
    April 7, 2017
    Posted on April 07, 2017 at 16:48

    That is great to know!!! (No other update than replacing

    HSICalibrationValue by

    MSICalibrationValue?)

    Last request please (as you have the failing HW): could you please make a test using following clock configuration (if possible to run it for a long time in a failing board)?

    It is generated based on CubeMX and using MSI to generate system clock (@ 80MHz) and USB clock with LSE trimming.

    /** System Clock Configuration
    */
    void SystemClock_Config(void)
    {
     RCC_OscInitTypeDef RCC_OscInitStruct;
     RCC_ClkInitTypeDef RCC_ClkInitStruct;
     RCC_PeriphCLKInitTypeDef PeriphClkInit;
     /**Initializes the CPU, AHB and APB busses clocks 
     */
     RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_LSE|RCC_OSCILLATORTYPE_MSI;
     RCC_OscInitStruct.LSEState = RCC_LSE_ON;
     RCC_OscInitStruct.MSIState = RCC_MSI_ON;
     RCC_OscInitStruct.MSICalibrationValue = 0;
     RCC_OscInitStruct.MSIClockRange = RCC_MSIRANGE_11;
     RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
     RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_MSI;
     RCC_OscInitStruct.PLL.PLLM = 3;
     RCC_OscInitStruct.PLL.PLLN = 10;
     RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV7;
     RCC_OscInitStruct.PLL.PLLQ = RCC_PLLQ_DIV2;
     RCC_OscInitStruct.PLL.PLLR = RCC_PLLR_DIV2;
     if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
     {
     Error_Handler();
     }
     /**Initializes the CPU, AHB and APB busses clocks 
     */
     RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK
     |RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2;
     RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
     RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
     RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1;
     RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;
     if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_4) != HAL_OK)
     {
     Error_Handler();
     }
     PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_USB;
     PeriphClkInit.UsbClockSelection = RCC_USBCLKSOURCE_MSI;
     if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit) != HAL_OK)
     {
     Error_Handler();
     }
     /**Configure LSE Drive Capability 
     */
     __HAL_RCC_LSEDRIVE_CONFIG(RCC_LSEDRIVE_LOW);
     /**Configure the main internal regulator output voltage 
     */
     if (HAL_PWREx_ControlVoltageScaling(PWR_REGULATOR_VOLTAGE_SCALE1) != HAL_OK)
     {
     Error_Handler();
     }
     /**Configure the Systick interrupt time 
     */
     HAL_SYSTICK_Config(HAL_RCC_GetHCLKFreq()/1000);
     /**Configure the Systick 
     */
     HAL_SYSTICK_CLKSourceConfig(SYSTICK_CLKSOURCE_HCLK);
     /**Enable MSI Auto calibration 
     */
     HAL_RCCEx_EnableMSIPLLMode();
     /* SysTick_IRQn interrupt configuration */
     HAL_NVIC_SetPriority(SysTick_IRQn, 0, 0);
    }�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

    -Amel

    To give better visibility on the answered topics, please click on "Best Answer" on the reply which solved your issue or answered your question.
    shingadaddy
    Senior
    April 7, 2017
    Posted on April 07, 2017 at 17:49

    48.0068 ~ 48.0069

    Unplugged and replugged 10 times.

    CubeMX seems to be a PASS. :)

    Duds after lunch.

    Just for Amel -I'll leave it running through lunch...

    shingadaddy
    Senior
    April 7, 2017
    Posted on April 07, 2017 at 17:05

    Yep. Test results hopefully BEFORE lunch and if not - shorty after...I'm gathering up the 3 DUDS to see if it fixes them as well..

    shingadaddy
    Senior
    April 7, 2017
    Posted on April 07, 2017 at 21:04

    Amel -  Still good. 48.0069Mhz

    And about the 3 DUD production PCB's that we had......

    They Enumerate now! Same Load  ----   'JAN.DFU'

    Now I have to find out where that was that I can give Jan points. :\

    Thanks everyone

    shingadaddy
    Senior
    April 7, 2017
    Posted on April 07, 2017 at 22:14

    I saw another question I didn't answer. Summary:

    The EVAL board CDC example code in STM32CubeL4 (1.6 ) can have USB clocking issues on the direct connected USB connections PA11 and PA12 when using MSI trimmed with LSE clock configuration. This can cause the device to be either ignored completely or cause DEVICE NOT RECOGNIZED responses from a USB host. This is because the 48Mhz MSI can be randomly TRIMMED way -WAY out of whack. The offending line in main.c is where it says :

    RCC_OscInitStruct.HSICalibrationValue = RCC_MSICALIBRATION_DEFAULT;

    rather than

    RCC_OscInitStruct.MSICalibrationValue = RCC_MSICALIBRATION_DEFAULT;

    So what does that bother? The first line leaves the *MSI* calibration UNTOUCHED, at some undefined value.

    Why?  Well aside from it being TYPEO 'H' instead of 'M' causing the MSI value to not be set as desired here,

    this struct is not initialized. Making the occurrence particularly, annoyingly RANDOM....

    This is the only mod needed for this issue.

    (Amel - No other update than replacing 

    HSICalibrationValue by 

    MSICalibrationValue!)

    Thanks to Jan for spotting this and ST for helping track it down.

    Shingy Son
    Associate
    August 25, 2017
    Posted on August 25, 2017 at 17:58

    Hi shingadaddy!

    I am very thanksful for your hardwork and most thanks to Jan and ST who contribute to this solution. Great!

    Shingy Son
    Associate
    August 25, 2017
    Posted on August 25, 2017 at 18:29

    I will be also too clad to have some images showing how you have mounted the USB-B dongle on the CN10 on your Nucleo L476RG. Thanks a lot in advance.

    SS

    JHinc
    Associate
    August 25, 2019

    Thank everyone for the help so far. I am able to talk to the LCD, using The BSP example. Too bad there is no easy way to copy the example without messing up the original example. John

    JHinc
    Associate
    August 25, 2019

    Oops, this wound up in the wrong spot. Very sorry.