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 30, 2017 at 20:05

Thanks Again JW.

Doesn't seem to be an output capable MCO tap on the clock tree for the 48MHZ. I might be missing it though. I could output PLL R with the same settings I suppose.

Yes 20PPM is 32.768KHZ crystal rating.

Honestly this is the demo code so I don't know (yet) what they do. I see in the RCC control SystemClock Config function, the call to the 'AUTO' CALIBRATION.

/* Enable MSI Auto-calibration through LSE */

HAL_RCCEx_EnableMSIPLLMode

();

Not looked at THAT function in detail but I guess I will.

No idea if their code calls that or some subcomponent of it anywhere else but startup. It would make sense it if WAS called periodically to cancel drift. (Active Auto Calibration?)

You'd think it might have been mentioned since 

I've had 2 Online support issues in starting on 3/7/2017 about this MSI/LSE and DRIFT. The first where I asked about this drift possibility TECH030747 on 3/7/2017 (Severity medium) was answered -  

'Never seen that happen before'

My Second, TECH031634 on 3/28/2017 (Severity CRITICAL)

has yet

to see anything, anywhere as a response.

That is very disappointing turn around time.

I'll have to look at the code a bit before I can answer your questions but thank you for the hints. Active cal periodically probably isn't as simple as calling

HAL_RCCEx_EnableMSIPLLMode

(); again I'd suspect.

[shingadaddy]

Posted on March 30, 2017 at 21:52

[EDIT] PS. If you are relying on RCC_CR.MSIPLLEN  , read it back to verify if it's really on, first.

They don't read back...... They call this

/* Enable MSI Auto-calibration through LSE */

HAL_RCCEx_EnableMSIPLLMode

();

That looks like THIS

/**

* @brief Enable the PLL-mode of the MSI.

* @note Prior to enable the PLL-mode of the MSI for automatic hardware

* calibration LSE oscillator is to be enabled with HAL_RCC_OscConfig(). 

(They did that)

* @

retval

None

*/

void

HAL_RCCEx_EnableMSIPLLMode(

void

)

{

SET_BIT(RCC->

CR

, RCC_CR_MSIPLLEN) ;

}

Then they just motor onward through this

/* Select MSI output as USB clock source */

PeriphClkInitStruct.

PeriphClockSelection

= RCC_PERIPHCLK_USB;

PeriphClkInitStruct.

UsbClockSelection

= RCC_USBCLKSOURCE_MSI;

HAL_RCCEx_PeriphCLKConfig

(&PeriphClkInitStruct);

/* Select PLL as system clock source and configure the HCLK, PCLK1 and PCLK2

clocks dividers */

RCC_ClkInitStruct.

ClockType

= (RCC_CLOCKTYPE_SYSCLK | RCC_CLOCKTYPE_HCLK | 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_DIV2;

if

(

HAL_RCC_ClockConfig

(&RCC_ClkInitStruct, FLASH_LATENCY_4) !=

HAL_OK

)

{

// Error_Handler();

}

[EDIT2] you have RCC_CCIPR.CLK48SEL set to 0b11, don't you

I seem to find it being READ and CHECKED, but just DEFINED here

#define

RCC_CCIPR_CLK48SEL_Pos (26U)

#define

RCC_CCIPR_CLK48SEL_Msk (0x3U << RCC_CCIPR_CLK48SEL_Pos)

/*!< 0x0C000000 */

#define

RCC_CCIPR_CLK48SEL RCC_CCIPR_CLK48SEL_Msk

#define

RCC_CCIPR_CLK48SEL_0 (0x1U << RCC_CCIPR_CLK48SEL_Pos)

/*!< 0x04000000 */

#define

RCC_CCIPR_CLK48SEL_1 (0x2U << RCC_CCIPR_CLK48SEL_Pos)

/*!< 0x08000000 */

It's their magic. Not mine. And I keep getting notified my post is being moderated. IF ST is looking over my shoulder - WHY NOT SPEAK UP?

Its pretty obvious I'm outside the intended example line here.

[shingadaddy]

Posted on March 30, 2017 at 23:36

RE-READING the MSI Autocal operation and looking at the clock tree diagram seems to indicate that the MSI itself is being put into a PLL MODE. So MSI could be output from MCO if that was deemed necessary. I was initially thinking PLL since it said 'PLL'. AS in the real PLL being driven by MSI.

But no

They appear to mean the MSI ITSELF ACTING as a PLL.

And so far I don't see how you control that AUTOCALING. There is SOFTWARE CALIBRATING but how that intertwines with the other mystery auto cal is -- well......A mystery.

[waclawek.jan]

Posted on March 31, 2017 at 10:35

[EDIT] PS. If you are relying on RCC_CR.MSIPLLEN  , read it back to verify if it's really on, first.

They don't read back...... They call this

Not they, *you* read it back.

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

JW

[shingadaddy]

Posted on March 31, 2017 at 16:16

Thanks Jan.

Yeah I get it. If that's not really set, then we're drifty as an RC oscillator in the wind.  Precisely! Theres 2 side to this however.

1. I need to see if there is a CODE problem and try fixing it. I might need a little help from ST.(If that is possible. Acts like I should be chasing a memory leak though on this one. But I do have 3 Hard fails and 7 working so thank goodness there is variety)

2. I need to leave their code AS IS and report the findings here so it can be examined by ST

Still no word on my critical TECH031634 online support request outside of the auto-generated email. And the following worries me. when I go to the Online Support, I see this

Note this is ALL ACTIVE ITEMS???. Maybe TECH031634 doesn't show up because there has been no initial response?

Still worrisome because it is certainly ACTIVE from MY standpoint. So since its making me think... Why isn't my new issue showing up? I just go fishing around by selecting the HUMAN BODY symbol upper right, then MY ACCOUNT, then ONLINE SUPPORT(RIGHT), The list of 4 items STILL doesn't show the TECH031634 However if I select SEE ALL on that page, THEN I can see the TECH031634 as ASSIGNED, plus ALL of the ones I've submitted. And ''ASSIGNED'' is possibly as official and efficient as a computer ASSIGNING it from a list of folks (Fred - next in line -  lets say) and good old Fred is on a 3 week vacation right now.

If someone is really looking into it, is it too much to ask for just a simple HUMAN response to that effect.

I'll try to get to register dump trickery. But its Friday! Meetings occur today. The fate of this probably at the forfront.

And there will be those questions like '' we've successful nailed down thousands of the M3062xxxxxxxxx and those FT2xxxx for micro/USB before. Why are we trying to use these new things and the company won't even respond to you?''

I'm starting to run thin on clever ROCK SOLID words here.

But I AM bringing in a hair dryer.

Tighter tolerance crystals (10ppm) should be here today or tomorrow. All signs point to that as a good possibility ''tree'' to be ''barking up'' for now.

[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 March 31, 2017 at 16:43

That's the plan. Probably add the 'LIGHT THE LED' test on that bit too when I get back to it. It should be a little later today. Appreciate your 'human' responses!

[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.

[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 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. 

[waclawek.jan]

Posted on April 05, 2017 at 17:30

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

JW