1
\$\begingroup\$

I have a problem with a custom STM32F417 board. On some boards the DFU bootloader works fine, while on other ones it fails to connect by USB. In my custom firmware all boards connect fine by USB.

  • Working boards have STM32F417ZET6, revision 2, date code week 11 / 2023
  • Not working boards have STM32F417ZET6, revision 4, date code week 4 / 2021

STM32 chip codes

This seems weird, why is the later manufactured part of earlier revision?

The issue seems to be related to the clock crystal. I have external 8 MHz 18 pF crystal ABM3-8.000MHZ-B4Y-T, Digikey part 535-13567-1-ND. Originally the board had 15 pF load capacitors, but that resulted in the clock running too fast. At this point, the bootloader was working unreliably. Switching to 27 pF load capacitors fixed the frequency but stopped bootloader from working at all.

Crystal schematic and layout is very basic. The PCB is four layers, with ground plane next to the top layer where the crystal is.

Schematic and layout

On working board, the bootloader startup looks like this (blue = VDD, yellow = PH1/Xout):

Working board bootloader start scope screenshot

On not-working board, same measurement of bootloader:

Not working board bootloader start scope screenshot

So the crystal is not starting. But in my own application firmware, HSE works fine:

Not working board, own firmware start

Why does the STM32 built-in ROM DFU bootloader fail to start the crystal?

\$\endgroup\$
4
  • \$\begingroup\$ There are no schematics of the crystal circuit at all to assess the correctness and some crystal details like exact load capacitance of the specific model you have are lacking but can be assumed to be datasheet defaults. \$\endgroup\$
    – Justme
    Jan 19 at 20:48
  • \$\begingroup\$ @Justme Thanks for the answer, it confirmed some suspicions I had. Indeed 18 pF load capacitance, the part I bought from Digikey is this. The oscillator schematic is very basic, just crystal to PH1/PH0 pins of STM32F417 and capacitors from either leg to GND, matching the Figure 22 schematic in reference manual. I'll update the question to add this information for future readers. \$\endgroup\$
    – jpa
    Jan 20 at 6:43
  • \$\begingroup\$ Thanks, I improved my anwer based on the newly acquired info and added a bit more content as well that might help balancing between CL, ESR and frequency. \$\endgroup\$
    – Justme
    Jan 20 at 10:19
  • 1
    \$\begingroup\$ Fortunately there are 8 MHz crystals with lower load capacitance available, so I can just change BOM without needing any firmware or PCB changes. \$\endgroup\$
    – jpa
    Jan 20 at 10:36

2 Answers 2

1
\$\begingroup\$

The crystal used is 8 MHz, has load capacitance requirement of 18pF and it has a maximum of 140 ohms ESR.

The circuit is correct as drawn, with the exception of the capacitor values which you are already aware of.

The PCB design looks OK, it should just work, there might be some room for improvement at least if you look at crystal design appnotes, but on average, this design does not seem in any way alarming.

Using the crystal and the oscillator parameters in the data sheets, you can calculate that the gain margin for proper oscillation is barely above the minimum safe value of 5, so not a good choise for the crystal to begin with.

Also the original 15pF caps were too small provided only 7.5pF of load capacitance, and even by taking into account for some stray capacitances, that will be far less than the required rated load of 18pF. Without further crystal parameters like the motional capacitance, the pullability cannot be used to estimate how much capacitance there was based on frequency deviation from nominal.

The next problem is that STM32F4 datasheet suggests having the capacitors typically in the 5 to 25 pF range, so the selection of 27 pF caps exceeds the recommendations.

So that crystal is not a good choise because it has too large capacitance and too large ESR so it is barely above the margin of safety for oscillation and it takes longer to start up.

Crystals with lower load capacitance and lower ESR start up faster.

So due to the two STM32 factory bootloader versions having different crystal startup time requirements, the crystal does not start fast enough for both factory bootloaders.

As a final note, different size crystals have different ESR, so if you go to a slightly larger package, you may find more suitable crystals with lower ESR.

Another option could be to use higher frequency crystal, as they have lower ESR and higher frequency means thr crystal will start faster. Higher frequency does reduce gain margin but lower ESR compensates it. Looking at the data sheet, a 12 MHz 18pF crystal has 60 ohms ESR so gain marging is marginally larger. Anyway a crystal with less loading capacitance is better.

ESR has only 1st order effect, but frequency and load capacitance have a cubic effect.

ESR can also be too low and the crystal may be driven with too much power. It can be compensated with series resistor, which unfortunately the design does not have.

\$\endgroup\$
1
\$\begingroup\$

DFU bootloader is documented in AN2606. The bootloader version can be checked from memory address 0x1FFF77DE. This indicated that the working devices have revision 9.1, while not-working ones have 3.1.

The change notes in AN2606 indicate that v9.1 has "DFU interface robustness enhancement." Searching further gives this table, indicating that the HSE startup timeout is just 0.79 ms for v3.1:

Table 178 from ST AN2606, indicating HSE timeout 0.79 ms

Adding some code in custom firmware to set GPIO pin high when writing HSEON and back low when HSERDY is detected allows to measure the crystal startup time.

With 20 pF load capacitors (not working): 0.88 ms avg startup time

Oscillator startup with 20 pF caps: 0.88 ms

With 15 pF load capacitors (working sometimes): 0.74 ms avg startup time

Oscillator startup with 15 pF caps: 0.74 ms

Conclusion: ST built-in bootloader v3.1 has too short HSE startup timeout to work reliably with 8 MHz 18 pF crystals.

Switching to crystal with lower load capacitance requirement will likely speed up the crystal startup enough to work reliably.

(Further screenshots available here)

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.