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.

[waclawek.jan]

Posted on April 05, 2017 at 17:30

So you managed to output the 48MHz clock somehow. How?

JW

[waclawek.jan]

Posted on April 05, 2017 at 18:30

In your registers screenshot above I now noticed that the MSITRIM field of RCC_ICSCR is not the default zero. Does your program write into this field?

JW

[shingadaddy]

Posted on April 05, 2017 at 21:00

Not having a precision counter in the production area. But 32.771Khz on a FLUKE. On ALL 3 DUDS. Yeah technically outside the 0.65536 tolerance of 20PPM but LSE they *ARE* a running and the Fluke reading might be....well you know.

We're swapping crystals on just 2 of the DUDS, for some 10 PPM units.

[Amel NASRI]

Posted on April 06, 2017 at 12:18

The mystery here should be related to the LSE:

- what is the reference of the crystal you are using?

- which capacitance values did you added?

- Did you checked if they are aligned with the recommended ones with STM32 microcontrollers (listed in

http://www.st.com/content/ccc/resource/technical/document/application_note/c6/eb/5e/11/e3/69/43/eb/CD00221665.pdf/files/CD00221665.pdf/jcr:content/translations/en.CD00221665.pdf

)?

For sure, it is recommended to measure LSE value with a Frequency Counter.

-Amel

[waclawek.jan]

Posted on April 06, 2017 at 14:21

In [STM32Cube_FW_L4_V1.5.0]\Projects\STM32L476G_EVAL\Applications\USB_Device\CDC_Standalone\Src\main.c I see this:

Can't this be the at root of the problem?

JW

[waclawek.jan]

Posted on April 06, 2017 at 12:28

Amel N wrote:

The mystery here should be related to the LSE:

I beg to differ.

The target frequency may be off by 2500ppm for a Device, as per USB2.0. The LSE either runs or not - 10ppm or 100ppm should make no relevant difference, unless the 'MSI PLL' (whatever it is) is badly broken.

I'd see the problem primarily in the 'MSI PLL'. There is virtually no relevant information on it in the DS/RM, which is a bad sign in itself. There's only a switch-on bit and a rather irrelevant (at least for USB usage, which appers to be the primary  reason for this feature) settling-timing in the DS. I don't believe in various magics - IMO, working of things has to be solidly documented. Yes, I am old fashioned.

The mysterious content of RCC_ICSCR.MSITRIM  just enhances suspicion.

There is also no relevant infomation on the MSI trim itself (which I'd ask ST to supply into the RM/DS, too). The frequency/value diagram for HSI in RM indicates, that there may be jumps in the frequency at certain values. Are there such jumps for MSI too? Can't the 'magic' be broken in that it does not take into account such jumps?

I am afraid this is something which can't be resolved at the user level and desperately needs factory attention.

JW

[waclawek.jan]

Posted on April 06, 2017 at 13:37

Amel N wrote:

The mystery here should be related to the LSE:

To elaborate on this hypothesis further, it may be worth trying to switch RCC_BDCR.LSEDRV to a higher setting, too.

And, switch on RTC if it is not already on, and observe if it ticks properly - especially at the moments when USB stops working.

JW

[Amel NASRI]

Posted on April 06, 2017 at 13:43

More relevant information about MSI may be found in

http://www.st.com/content/ccc/resource/technical/document/application_note/60/15/94/5b/15/bb/4f/9e/DM00210926.pdf/files/DM00210926.pdf/jcr:content/translations/en.DM00210926.pdf

. We may find there more details about calibration and trimming process.

-Amel

[shingadaddy]

Posted on April 06, 2017 at 16:00

You folks have no idea how appreciative I am of the responses. I'm getting really good support direct also.

1. I'll be tinkering with the DRIVE bits.

2. I'll be fixing the blivits that Jan is kindly pointing out --  Unititialized vars , MSI/HSI goof

The register dump shows 0 which is by LUCK I guess.

3. I'll be renting a VERY high accuracy freq counter if need be.

I am approaching a disappear time and will resurface later today but for a question that's pretty direct:

By calculation when using MSI trimmed with LSE

What should the output freq of the MSI be if the LSE is 32767.00000000000  HZ?

What should the output freq of the MSI be if the LSE is 32768.00000000000  HZ?

What should the output freq of the MSI be if the LSE is 32769.00000000000  HZ?

Maybe I should be able to calculate this. I'll be looking when I get back

Rememeber - The LSE's ARE all running.....

Thank you all.

[waclawek.jan]

Posted on April 06, 2017 at 14:19

More relevant information about MSI may be found in

/external-link.jspa?url=http%3A%2F%2Fwww.st.com%2Fcontent%2Fccc%2Fresource%2Ftechnical%2Fdocument%2Fapplication_note%2F60%2F15%2F94%2F5b%2F15%2Fbb%2F4f%2F9e%2FDM002109pdf%2Ffiles%2FDM002109pdf%2Fjcr%3Acontent%2Ftranslations%2Fen.DM002109pdf

. We may find there more details about calibration and trimming process.

Thanks, Amel.

There is a trim-versus-frequency chart for MSI, which shows monotonically rising dependency, although a bit steep on the upper end. IMO this sort of information ought to be in the DS.

There's no information whatsoever on the 'MSI PLL' there, though.

Jan

[EDIT]

Estimating from that trim graph for MSI, the 'tuning step' around the center is roughly 10-20kHz per +-1 in TRIM, which at 4MHz which is the nominal frequency for that graph converts to 2500ppm... it is thus next to impossible to manually trim the MSI to the precision required for FS USB Device.

That also IMO precludes an internal mechanism which would change MSITRIM.