2017-03-28 03:21 PM
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.
Solved! Go to Solution.
2017-03-29 02:06 PM
If you suspect clock issue, why don't you simply add a normal HSE crystal to the Nucleo and run out of that?
It's a Nucleo-64, isn't it - it even has the pads needed for that.
JW
2017-03-29 03:19 PM
And on Nucleo 64, all you have to do is apply the 2 MCO jumpers SB50 and SB16 and you have a 8 MHZ source from STLINK. Set up your clock config to use HSE and you're in business. That 8MHZ signal goes into your PH0-OSC-IN pin.
The PH1-OSC-OUT pin can be freed up with setting the HSE BYPASS if you want but it isn't necessary. I remember my little HSE BYPASS RUNAROUND. :\
2017-03-30 08:27 AM
And I did Just that.....
Today I reverted back to testing one of my Nucleo PCB’s from ST that I thought had a heat / freq creep drift problem.
The code running in the device was set to use the MSI (RC oscillator internal) TRIMMED with the 32.768KHZ crystal
source.
Which ST claims is GOOD ENOUGH TO RUN THE USB.
Well on Nucleo, you ALSO have the possibility to use the HSE clock input (HIGH SPEED EXTERNAL).
This is either by CRYSTAL OR by external CLOCK DRIVER. C
rystal controlled preferably.
The DEBUGGER part of the nucleo allows you to use jumpers SB16 and SB50 to JUMP an 8 MHZ crystal controlled
source from the debugger to the target micro to use as HSE clock. (
external CLOCK DRIVER. C
rystal controlled
)I quickly set up a fast CLOCK SWITCH build routine and set the clock to use MSI Trimmed with LSE as was the desired target.
And I HOPED after an hour or so it would FAIL.
IT DID !!!
I quickly rebuilt to use the external HSE input
ENUMERATION WORKED PERFECT
I quickly rebuilt to use the MSI / LSE
ENUMERATION FAILED……
I'm going to calm down and repeat this a few times and then ask where I missed the 'MAYBE' or 'ONLY IF'
qualifiers in that 'GOOD ENOUGH' claim. Right now, at tolerance of 20PPM -- IT ISN'T
I think I might have a real nasty one by the tail.
2017-03-30 10:44 AM
I'd output the 48MHz USB clock somehow and measure it with a precise enough frequency counter.
Right now, at tolerance of 20PPM -- IT ISN'T
That's the 32kHz crystal's rating I presume. MSI won't be that good.
Looked into USB 2.0 - FullSpeed device data timing error is max. 2500ppm.
It still might be also some other software error introduced by the MSI conditioning software. Do you perform it regularly or only once at the startup?
JW
[EDIT] PS. If you are relying on RCC_CR.MSIPLLEN , read it back to verify if it's really on, first.
[EDIT2] you have RCC_CCIPR.CLK48SEL set to 0b11, don't you
2017-03-30 11:05 AM
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.
2017-03-30 12:52 PM
[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.
2017-03-30 02:36 PM
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.
2017-03-31 01:35 AM
[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
2017-03-31 07:16 AM
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.
2017-03-31 07:43 AM
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!