STM32F401RCT6 requires a reset to run code

[andrew sauter]

We have a new revision that has a significant population of boards with this intermittent power issue.

 

steps to reproduce

• press power button
• power applied to the MCU 
• the MCU only prints a single debug message, then halts
• press reset: device works normally

 

resolves issue

• If I enable the hardware watchdog is takes a variable time period where I see these single debug statements before running normally
• This issue appears to be related to the rate of change of the MCU VDD. If the VDD changes very slowly e.g. walking a bench PSU up 100 mv per sec it works, else it halts
• replace the MCU, since most of the boards seem to work

diagnostic

• with various brown out levels
• I have tried using older code w/ and without a bootloader
• manully undoing some of our changes in this board revision
• with other power rails and peripherals not enabled / connected
• reading the SCD registers one device showed a hardware fault and one did not
• my nRST rises after 3.3V and if I force hold nRST low while applying power and then release, it does not resolve issue

many thanks

[andrew sauter]

our VDD rise time is much greater than the minimum speified in the datasheet 20 us / V and I do not see any other critical sequencing. Yet to test adding a delay in code execution.

[Tesla DeLorean]

Make sure BOOT0 is pulled low, so isn't floating and high-ish as the MCU gains viability at around 1.2V

Check VCAP levels and caps. Adequate bulk capacitance, 2u2 individually or 4u7 collectively. Should be around 1.25V

Have HardFault_Handler() and Error_Handler() output actionable data.

Watch for slow start time of external oscillators and/or the PLL

[waclawek.jan]

Just adding to @Tesla DeLorean's list: make sure *all* VDD/VSS pins (including analog and VBAT) are connected as appropriate.

> If I enable the hardware watchdog

Tell us all the details of this.

JW

[andrew sauter]

Hello All,

 

Boot0 is low, VCAP is stable, VDD and VSS are solid, our bypass values are 1uF per pin 0603, also we have a bulk 22 uF ceramic, we are using internal RC for clock and external 32 kHz crystal for RTC

 

RTC is implicated as cause

if I force the RTC to fail (by removing a series element or loading with parasitics), it presents the same issue as that described above, we get a single debug message from the bootloader then nothing, if I have the HW WDG enabled it endlessly performs these two steps 1) prints the bootloader debug message, 2) WDG resets device, and but never starts up. If I do not for the RTC to fail it will eventually startup.

 

Questions:

-could anything else cause a similar issue, there was a very small change in our copper (perhaps our PCB fabircator have a different process), so this is a surprising finding.

-is there a best firmware practices working with the 32 kHz crystal, initialization delay etc?

-I am exploring how to better estimate or measure our crystal parasitics

[waclawek.jan]

Is VDDA connected directly to VDD?

How is VBAT connected?

What is the timeout waiting for LSE to start up, and what happens if that timeout, well, times out? Note, that it may take a surprisingly long time (tens of seconds) for a 32.768kHz crystal oscillator to start up.

JW

 

[andrew sauter]

Our device has a power switch so our MCU has no power until it is turned on.

[waclawek.jan]

What is the timeout waiting for LSE to start up, and what happens if that timeout, well, times out? Note, that it may take a surprisingly long time (tens of seconds) for a 32.768kHz crystal oscillator to start up.

JW

[andrew sauter]

We created a test FW to measure the RTC startup time and the median was 1.5sec and the repeatability was mostly +/- 20% .

 

However, two assemblies were over five seconds, I have tracked the issue to the MCU!

• the capacitors measured correctly
• replacing did not improve
• replacing the crystal did not improve
• moving one chip to new bare fab did not improve
• Installing a much smaller cap dramatically improved the startup time

20 pF ~10 seconds

18 pF ~7 seconds

15 pF ~2.5 seconds

13 pF ~1.7 seconds

8 pF ~0.8 seconds

 

Do you have any suggestions:

1. In the recent revision I thought I made a minor reduction in the inductance of cap layout might that have shifted our resonance and caused our issue? Based on testing of these units, I presume we can reduce our load capacitance some to get all of these to startup faster. I see only a few pF between a 7 second and 2 second startup time!
2. Do you have any other guidance on how to design the firmware to tolerate these outliers? We are finalizing the RTC startup time allowed, but currently this process is blocking so it requires a several second delay during startup, which is a bad user experience.
3. Why might two MCUs be such outliers? is there any reasonable explanation for this result? Can we expect this in the future?
4. Any concern about crystal vendors (?) and cap specification (C0G)?

Best.

[Tesla DeLorean]

Ok, but what part# for your 32.768 KHz, is it a 6, 9 or 12pF class?

The F1, F2, F4 all really want 6-7pF oscillators,  and the caps you're using all strike me as being rather high

 

MC306-G-06Q-32.768 (manufacturer JFVNY), pair of 6.8pF

Regular C0G/NP0 caps should be fine. You want very short traces and board capacitance, so tight to the IC

[andrew sauter]

These boards are built with this crystal  Raltron 32 kHz 12.5 pF

Layout: there is a continuous return on adjacent to the top and bottom side, but we change reference as it goes from top to bottom layer (no transitional via) there are two series elements both zero ohm, no ground cut, no guard trace, but also no significant adjacent noise sources.

My parasitic allowance was ~3 pF perhaps it is much higher. Which is surprising and the bare board does not measure higher using LCR meter DE-5000

 

[Tesla DeLorean]

Lot going on there, I wouldn't have gone with the via's like that, just straight to the crystal

[waclawek.jan]

I don't quite understand how the return is arranged, but it should not be tied to common ground but should be separate and as short as possible. Plus what @Tesla DeLorean said above. See AN2867.

OTOH, a really well designed crystal oscillator start up time *is* long (this is an implication not an equivalence, i.e. long startup does not mean the design is good). Thing is, that the oscillator starts up from picking up and amplifying noise, and well designed oscillator doesn't have too much noise to start from. 10 seconds is quite normal (and timeout should be even longer), so the application has to deal with this.

JW

[andrew sauter]

AN2867 is great, I will also be performing the gain margin test, by adding 5x the crystal ESR and verifying it still works, also https://resources.altium.com/p/making-most-your-crystal-oscillator

 

It appears we have two MCUs that are outliers in that they require more stabilization time for their RTC. Swapping crystals, capacitors and bare boards, the issues seem to track with these two MCUs.

 

Perhaps we were just marginal to begin with as there was much more parasitic capacitance. I can even omit the load caps, with the outlier MCUs and it starts up in 300 ms. Yet to replicate on a more typical MCU. I presume the more typical MCUs will just want a lower value capacitance. I think this could be caused by gate propagation delay in the MCU crystal amp, not sure.