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