STM32L476 USB inconsistencies.

[shingadaddy]

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.

[Amel NASRI]

Posted on April 06, 2017 at 14:37

Indeed this is an error that has to be fixed in USB_Device examples. I'll take care to report it internally.

However, I am not sure that it is the root cause of the issue as the reset value for MSITRIM bits is 0.

It is interesting if

Palmer.Randall

‌ may share current RCC registers snapshots (if there is any modification compared to previously shared ones).

-Amel

[waclawek.jan]

Posted on April 06, 2017 at 14:48

However, I am not sure that it is the root cause of the issue as the reset value for MSITRIM bits is 0.

RCC_OscInitStruct is a local variable in  that function, and I don't see any explicit initializer for the entire struct. It means that the MSICalibrationValue field of it has an undefined value, whatever was in the piece of stack where that variable is located.

As this function is called early in the program, it is quite likely it contains an 'untouched' value from the SRAM. Upon powerup, SRAM cells tend to flip to a certain position depending on miniscule manufacturing process variations, which might explain why some boards systematically work and other don't. There of course might be other explanations, too - undefined is hard to define 😉

HAL_RCC_OscConfig() then subsequently uses this 'random' value to fill in the RCC_ICSCR.MSITRIM field.

JW

[Bertrand DENIS]

Posted on April 06, 2017 at 18:04

Hello,

1) If the DFU loader works all the time, it tends to prove that the HW is OK as it uses the 'MSI auto calibrated by the LSE mode'. So I don't see why it should not work when your code is running.

2) As written in the datasheet if the Crystal is 32.768 kHz the MSI output in this mode (11) is 48.005 MHz.

So if you are at 32.767 kHz, you will get 48.005 x 32.767 / 32.768 = 48. 0035 MHz

for 32.7669: 48.005 x 32.769/32.768 = 48.0065 MHz

Still OK for an USB specification (+/- 0.25 % so 2500 ppm). That is to say. Min : 47.88 MHz. Max: 48.12 MHz

Bertrand

[shingadaddy]

Posted on April 06, 2017 at 20:13

Thank you Bertrand. Initially there was of course a heavy interest in the LSE, Crystal, caps maybe doing some dirty deed. It's been my experience with crystals where that is usually a STARTUP concern and secondary a power concern. But my LSE's are ALL running. And the worst OFF reading we get is from a Fluke and that's 32.771Khz.

Not enough to convince the MSI to ZING off to 55-60Mhz for sure.

I really want this to be something silly I missed. OR maybe just some combination of clock that the overall system gets heartburn over - THAT CAN BE AVOIDED WITH SETTINGS....Not with blue wires, dangling components and new copper.

[shingadaddy]

Posted on April 07, 2017 at 00:52

Fred *MIGHT* have it fixed for now.

Fred?

Add VAR in main

uint32_t fred = 0 ;

Then -

Add those lines on my Nucleo that misbehaves -   48.005MHZ out MCO pin for MSI.

Comment these out -  TURBO! 57.488MHZ

Repeat 5 times.

Same results. LINES IN = GOOD - LINES OUT = BAD.

 I let my contacts know.

And - Yeah maybe just ONE of those lines might do it.

More tomorrow I'm sure.   (I need to grab one or all of the production Duds...)

[shingadaddy]

Posted on April 07, 2017 at 01:28

Yep I'll get that too. I thought I already did, but I've flipped files around a little today. Checking the register its 0's

Let you know here shortly...   Flipping files around again

[shingadaddy]

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 !

[waclawek.jan · Accepted solution]

Posted on April 07, 2017 at 00:57

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

JW

[Jan Waclawek]

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

[Bertrand DENIS]

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.