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.

[shingadaddy]

Posted on March 31, 2017 at 17:31

Not stuck the LED in yet and this was QUICK by an unproficient user (me)

Breakpoint inserted HERE just after it gets set in line 434

Code

RCC_CR Register

Thats the important one. I'll have to play more to get ''ALL'' of them on here.

Those other 2 bits floating around on the left.... =    RCC_CCIPR.CLK48SEL   - No Wrong register I suppose..

BUT THEY ARE IN THE RIGHT BIT SPOTS !    I'll look.

[waclawek.jan]

Posted on March 31, 2017 at 16:37

In the debugger, read out and post the content of all RCC registers.

Meetings? Who cares about meetings? I would never work for people who prefer meetings to solutions (yeah but that's me, maybe that's why I still don't have those fancy leather trousers and a pair of colts 😉 )

JW

[shingadaddy]

Posted on April 01, 2017 at 01:07

Better?

[shingadaddy]

Posted on April 01, 2017 at 17:06

WHAT??!?!?    Oh... Its Saturday....   Is that still called a WEEKEND?

[Amel NASRI]

Posted on April 05, 2017 at 10:42

Hello

Palmer.Randall

‌,

Please note that the OLS tickets highlighted in your previous comments will take required care by our Support team.You will be contacted soon on this regard.

Now, in forum side, it is interesting to get the current status.

After your several trials and updates, could you please describe the current situation? Giving more details about the schematic of your new PCB as well as used FW and SW will be helpful to understand the problem and try to reproduce it at our end.

With Regards,

-Amel

[shingadaddy]

Posted on April 05, 2017 at 18:08

As it turns out, the MSI has is OWN PLL MODE as you probably already know. And to use MSI trimmed with LSE clock

for USB you have to set the clock source for USB to MSI DIRECT.   NOT thorough one of the many OTHER PLL's. So you simply output MSI on MCO.   And my 3 duds MSI's are as follows

PCB #106:  60.69MHz

PCB #107:  58.45Mhz

PCB #109:  54.14Mhz

Yeah. I just sent production a binary that will output LSE now... We'll see what THAT turns up but on the Nucloe where I've already done this little exercise, my scope says 32.769Khz.   And Put back immediately the OTHER way my MSI is 57Mhz.  (It's still *warm* I guess)

[shingadaddy]

Posted on April 05, 2017 at 18:21

And running via debugger, I can pause it randomly and the RCC CR and CCIPR are correct. As shown above but the CCIPR has the upper 2 bit that are 1's are now 0's since I'm back to the raw demo code. (No AtoD's)

[shingadaddy]

Posted on April 05, 2017 at 16:32

Thanks Amel. I am currently (since 4/3) receiving very good TIMELY support.

I have sent my schematic. I use the STm32CubeL4 EVAL USB CDC example program with the LED inits and calls commented out - On a Nucleo64 (Stm32L476rg) with an added B type USB DEVICE connector.

Presently I have a Nucleo that, after some running time period, the target processor likes to fire up [edit] the MSI at 57Mhz instead of 48Mhz. (Random TURBO MODE I guess) . USB does NOT like that.

LSE is 32.769Khz per MCO.  

57Mhz?  Any possible math probabilities there?

I have 10 PCB's that WE had made. All identical, all work under DFU and only 7 of 10 will enumerate. With the same EVAL binary. Highly suspect CLOCKS. Trying to determine if RELATED to Nucleo issues.

Also on the Nucleo, when it decides to go TURBO,  I can switch to HSE and it works fine. Switching BACK to MSI trimmed with LSE and it fails again. 

[shingadaddy]

Posted on April 05, 2017 at 18:50

I looked quickly and only see reference to ICSCR in a GET VALUE

void

HAL_RCC_GetOscConfig(

RCC_OscInitTypeDef

*RCC_OscInitStruct)

RCC_OscInitStruct->

MSICalibrationValue

= (

uint32_t

)((RCC->

ICSCR

& RCC_ICSCR_MSITRIM) >> POSITION_VAL(RCC_ICSCR_MSITRIM));

RCC_OscInitStruct->

MSIClockRange

= (

uint32_t

)((RCC->

CR

& RCC_CR_MSIRANGE) );

I suspect the MAGIC of LSE autotrim might fiddle these maybe?

[shingadaddy]

Posted on April 05, 2017 at 18:54

Now here's a headspinner..       The LSE can take as much as 2 seconds to START?

Wonder if the demo code waits that long, for it to be STARTED?  

I gotta eat.