# STM32 oscillator troubleshooting

I’ve designed a PCB using the STM32F373VBH6 MCU and I’m having issues with getting the board to work. Specifically, it seems like the main issue is that the MCU won’t even boot up.

I’ve probed around the board for strange behavior, and I think there might be something wrong with the crystal oscillator, based on what the oscillator signal looks like on the oscilloscope:

This event happens once, on powering the board, and after this event the oscillator signal is completely dead.

Here’s the piece of the schematic with the crystal oscillator:

I’ve used an 8 MHz crystal, the ECS-80-10-30B-CKM. I’ve calculated the values for the load capacitors according to the AN2867 oscillator design guide for STM32 MCUs and gotten the following results:

gmcrit = 4×ESR×(2πF)2×(C0+CL)2= 4 × 100 ×(2π×8 MHz)2×(5pF+10pF)2=0.227 mA/V

My oscillator transconductance is found on p 74 of the STM32F373VBH6 datasheet, and is 10 mA/V.

My gain margin then becomes 10/0.227 = 44. According to the oscillator design guide, any margin larger than 5 should be fine.

I then calculated what load capacitors I should have, and once again followed the equation in the oscillator design guide:

CL= (CL1×CL2)/(CL1+CL2 )+CS= (10pF×10pF)/(10pF+10pF)+5 pF=10 pF

Here I assumed that my stray capacitance would be approx. 5 pF, as this seems to be a common value based on some googling, and partly this thread: Stray Capacitance for Crystals That would give me that my parallel external capacitors should have a value of 10 pF, which I’ve used. The F373 evaluation board from STMicro uses 20 pF, but that board has a different crystal which I haven’t managed to find the datasheet for, but here’s the schematic for the F373 Eval board that includes the HSE oscillator:

I've also tried exchanging the external capacitors for 22 pF caps; it didn't change the oscillator behaviour.

I’ve used a value of 0 Ω for the REXT resistor. I’m not sure this is correct, but it's what is used on the F373 Eval board, but I’ve also tried swapping it out for 100 Ω, 500 Ω, 1 kΩ and 2 kΩ. None of those values changed the way the signal looked on the oscilloscope; it still looks exactly the same as the oscilloscope image I’ve linked.

My layout for the oscillator looks like this, it’s placed as close to the MCU as possible, with a dedicated, local GND plane that’s only connected to a GND plane on layer 4 with a single via, and with the GND plane on the 2nd layer cut out so there’s nothing directly beneath it.

2nd layer:

My questions are:

1. Have I interpreted and used the equations from the STM32 Oscillator Design Guide app note correctly, or is there a calculation error?

2. What can the behavior that I see on the oscilloscope indicate? Am I correct in that it looks like the oscillator can’t start oscillating?

3. Is there anything else beyond the gain margin, external capacitor values, and external resistor values that I can improve or that can be the source of error for why this oscillator is not oscillating?

EDIT: Since several people pointed out that the crystal is not what's giving me errors here, and someone requested the schematics, I've included the full MCU schematic below. What I'm specifically trying to solve is that my software engineers tell me that the bootloader should load automatically and if the MCU is working it should pop up as a USB device when I connect a cable from my PC to the USB connector on the PCB, which is connected to the USB pins on the STM32. But it doesn't pop up as a USB device, and I can see no activity on the D+/D- pins of the USB bus. I'm far from an embedded wizard, so I've for now opted on trusting the SW people, and I'm working with the assumption that there's a hardware error here.

Here's the MCU schematic, MCU Power schematic and the USB connector implementation, which should be working (if the software engineers are correct in that the STM32 should pop up as a USB device out-of-the-box). Also, I've already realized that the debugging LEDs on the MCU schematic have been implemented wrong, silly mistake by me.

MCU:

MCU Power:

USB Connection:

EDIT2: As several pointed out, this was not an issue with the crystal at all, rather an issue with my understanding of what the design should do when powered without a software flashed to it. When I followed the various app notes and resources linked by different people here I decided to bring BOOT0 high, which immediately made the crystal come to life and start to oscillate. The USB communication still didn't work, but there the issue was that the USB2.0 specification requires a 1.5k pull-up resistor on the D+ line. I had that, but that pull-up was tied to a certain GPIO of the MCU, which the firmware engineers had recommended and said would work. It didn't, but when I pulled up the D+ line manually through a 1.5k pull-up the USB communication started working as well. So, problems solved, the design is at least communicating and can be flashed. There are probably electrical issues left to discover, but for now it's working! Thanks for the help and pointers!

• Oscilloscope shows some "fuzz" (not oscillations), but perhaps some clock activity nearby. Could the MCU be using internal clk source? It appears that for a short timespan, this oscillator is enabled, and rising to its bias level near half the supply voltage - oscillations should start soon after...but it is shut down before that happens. Commented Oct 1, 2022 at 12:32
• You are 100% guaranteed barking up the wrong tree here. As Justme points out, the HSE oscillator only starts up when commanded to by code - the MCU boots up using its HSI. Show us the rest of the MCU pin connections - in particular power supply, JTAG, Reset, BOOT pin(s), etc. Commented Oct 1, 2022 at 13:08
• I've included schematics now, and some explanation on what I'm specifically trying to solve. Commented Oct 1, 2022 at 13:33
• Well, the bootloader does not magically just respond. You need to reset the MCU into bootloader mode. And even when MCU is put into bootloader mode, there are several issues why it might not even go check the USB pins because UART pins might have activity. And since the USB pull-up is software controlled by MCU, how would it possibly be able to pull-up the USB pin which is required to detect USB? Commented Oct 1, 2022 at 16:51
• A good first check with STM32 boot problems is to measure the voltage on NRST pin. You should see it rise about 300 µs after VDD, indicating that at least the chip is getting power and the internal reset circuit is working.
– jpa
Commented Oct 2, 2022 at 12:49

There are three bootloader ports in the STM32F373VBH6, USART1, USART2, and USB(DFU). The external crystal oscillator (HSE) must be operational at one of several frequency choices. 8MHz will work. If HSE is not detected, then USB boot is not available. It will still boot over one of the two USARTS. So you may still have a hardware problem. You might have to set a code on certain pins, or send a particular bit pattern on the specific input.

There are several resources available to help.

To boot USB:

1. HSE must be working. (8MHz is good).
2. USB cable must be detected. ( You should confirm how this works. I think it is the 1.5k pull-up on DP that provides bias for detection, or VBUS detect.)
3. Sufficient delay is required for the reset code to detect and measure HSE then detect the USB cable.

Then, I think a bit pattern is send to the boot loader to start it up. Make certain VBUS detect is connected to the correct pin.

You can test for HSE at reset by writing test software and download through JTAG/SWD, that will test the clock sources and clock tree.

I am not familiar with this version of the STM32 series so this is the best that I can give. Dig into the data sheets, write some test code.

Cheers

Edit: I am adding this in so thet I can include an image for @Justme in response to his comment below. The figure clearly shows boot loader start up at the end of a software sequence.

I would call the software, starting at reset that configures the hardware for bootloader operation, reset firmware. I don't know how reset "knows" to execute code or look for a bootloader.

• HSE is not needed unless USB connection is tried. Bootloader may have already be listening on the UARTs if they have any activity. 1k5 resistor can't be enabled because it requires firmware to run and it won't be running in bootloader. Bootloader has no VBUS detection. Commented Oct 1, 2022 at 19:43
• @Justme: Right the bootloader doesn't do the detection. The reset firmware does. The OP indicates that the USB boot-load is the desired one. For this particular STM32, The reset firmware can detect if HSE is available, can determine the frequency, configure the system clock to 60MHz, configure the USB clock to 48MHz and detect the USB cable. The only way to detect the presence of USB cable is by VUSB or the 1.5k pull-up. Only after all of this is the bootloader started up by signaling from the host. Commented Oct 1, 2022 at 19:56
• I don't understand what you mean by reset firmware. There is no such thing as reset firmware. That's the factory bootloader you are talking about. The system clock is also not 60 MHz but 48 MHz. And there is no VUSB detection. You can read the AN2606 you linked for further info how it works. Commented Oct 1, 2022 at 20:12
• @Justme: See my Edit Commented Oct 1, 2022 at 20:35
• That's just nit-picking if you only want to call the separate bootloader loops as bootloaders. The whole thing is just one big factory bootloader which initializes the MCU and peripherals and listen which of all the possible ones should be used. If you want a better name, it's called system memory boot mode, but even the AN2606 just calls the whole thing as a bootloader (see page 1, Introduction, of AN2606). Commented Oct 1, 2022 at 20:45

This may not be what you want as an answer, as you have designed everything related to the crystal correctly, but you have an incorrect understanding how it should work.

If the MCU does not even boot up, the crystal can't be the issue, because the MCU must and will boot up without a crystal, and it must run software in order for the software to turn on the internal oscillator circuit and use it.

So the crystal pins do nothing unless software is running.

The problem is elsewhere.

• Thank yo for the reply! That's some good information. My assumption, or guess, was that the crystal behaviour I'm seeing indicated that the MCU is trying to the get crystal to oscillate, but can't for some reason. But yeah, it might very well be that the issue is somewhere else completely I guess. Commented Oct 1, 2022 at 12:16
• Well, incorrect assumption, and other hardware and software issues are not ruled out yet, and can't be without seeing how rest of the MCU is connected and what software it is running. Have you loaded any software to it? Have you got the bootloader running? One or many boards? Commented Oct 1, 2022 at 12:28
• The bootloader is not running, and the software engineers are saying that it should start running the bootloader without any programming. We've not loaded any softare to it as we haven't been able to communicate with the MCU. Commented Oct 1, 2022 at 12:31
• @LarsPetersson You should not trust what they say. Ask how they try to start the bootloader, but it needs to be triggered in certain ways. JTAG and SWD will work without bootloader starting, but if that does not work then there is a hardware problem. Commented Oct 1, 2022 at 12:41
• @LarsPetersson: You need AN2606: st.com/resource/en/application_note/… Commented Oct 1, 2022 at 20:02

The ECS-80-10-30B-CKM crystal has a stated load capacitance of 20 pF typically and, for most crystal manufacturers, this means the combined capacitance of the input and output (in series) must add up to 20 pF. This means that the input capacitor should be more like 40 pF and likewise the output capacitor. In other words 40 pF in series with 40 pF equals 20 pF: -

Your use of 10 pF capacitors is falling short of what is needed and could easily be the reason why your oscillations do not begin. Given that the above states the minimum loading capacitance is 8 pF, that requires at least 16 pF on both sides of the crystal.

• What you've circled there says that the Load capacitance is specified in the part number. I interpret the part numbering guide at the bottom of that page of the datasheet as that the Load Capacitance for the ECS-80-10-30B-CKM to be 10 pF. Is that not a correct interpretation? Commented Oct 1, 2022 at 12:19
• The datasheet is generic for a series of crystal parts you can order. The -10- in the part number means 10pF load capacitance for a specific orderable part. Commented Oct 1, 2022 at 12:22
• OK point taken but, if the specified load capacitance is 10 pF then you need to use 20 pF capacitors either side of the crystal @LarsPetersson Commented Oct 1, 2022 at 12:30
• Ok, why is that? Just trying to understand, from the equation in the app note the calculation for external caps would still be 10*10/(10+10)+5=10 pF? Or am I misunderstanding that equation from the app note? Commented Oct 1, 2022 at 12:33
• @LarsPetersson a loading capacitance of 10 pF requires two 20 pF capacitor on each pin to ground. It's confusing I know. The F373 Eval board uses 20 pF capacitors if you look carefully. I don't know what app note you mean. Commented Oct 1, 2022 at 13:04