cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F401 does not seem to boot on custom PCB!

AD_716
Associate III

Hello everyone, I am new to this community and I am starting to use the STM32F401 from the Nucleo platform. Thank you in advance for your indulgence and your help.  

So I programmed a test code on nucleo which works well. For my final project, I need to integrate only the microprocessor, so I cut the V-Link card of the nucleo and used the DFU Mode to program the chip via USB. Everything works fine, I added a "BOOT" button that allows me to pull pin 60 (BOOT) to 3.3V and I can program the STM via STM32CubeProgrammer.

In a second step, I created a test board following the Nucleo schematic indicated in the manual. I just wanted to reproduce the same assembly as on the Nucleo board but with my PCB.

The PCB was assembled by the PCB manufacturer with a Pick & Place.

When I turn on my custom board, I have all the power supply pins receiving 3.3V, I put all the decoupling capacitor as shown on the diagram, check all the connections to the tester, but despite that, the chip does not seem to start. Impossible to start in DFU mode to load the 1st program.

I attach a schematic of my assembly and a picture of the PCB.

I have spent hours reading and searching the various forums but I have not found why my MCU does not boot!

Any help will be welcome, thanks in advance for your answers.

Sincerely

Antoine


_legacyfs_online_stmicro_images_0693W00000bkAXAQA2.png
_legacyfs_online_stmicro_images_0693W00000bkASFQA2.png

1 ACCEPTED SOLUTION

Accepted Solutions
AD_716
Associate III

Hello everyone,

I'm coming back to you regarding my BootLoader problem which in fact was not solved!

Indeed after thinking that the error comes from a soldering defect, I realized that the DFU mode only start when the MCU was "bathed" in the Flux cleaner (Product to clean the soldering). After 2 days of headache to check everything, re-soldered, tested, change the quartz, the capacitor .... In short still nothing, the MCU in bootloader mode does not work if the condition of being bathed in this liquid.... 

A friend then made me notice that the product in question must be conductive...

After the product, it was my fingers that in contact with some pin allow me to start in DFU mode... So we searched on a capacitive problem, design defect, ground plan.... Nothing yet!

From there we went back to the Notice and my friend found in the DOC RM0368 that BOOT 1 should be connected to ground! The PB2(28) pin is in fact the BOOT 1 pin that should be connected to ground... so the product made contact.

After checking, on nucleo this pin is not connected to anything... no pulldown, no strap... but still the MCU starts in Bootloader Mode on nucleo. It is apparently an error on the development board and it works by chance... If someone has an explanation? I'm interested!

Conclusion, I followed the official scheme and there was a connection missing!

Everything is working fine for the moment, it seems I connected PB2 to GND!

I hope this post can help others!

A huge thank you for your answers and your help,

See you soon

View solution in original post

30 REPLIES 30
ONadr.1
Senior III

Did you change the oscilator configuration from external clock (Nucleo) to extenal crystal?

AD_716
Associate III

Hello, 

Thank you for your quick response

I just wired DM, DP, and BOOT. 

I removed the 0ohms resesitance that connected the V-Link clock to the MCU. I then installed a 8Mhz Quartz with 2 22Pf capacitors to do without the V-Link clock.

Then the STM on nucleo started in DFU mode, I was able to program it this way without any problem.

I reproduced my schematic identical to the nucleo, could I have made a mistake in the connection?

When I test the crystals on necleo, it goes into default when the tip of the oscilloscope touches the pin of the quartz. So I can't see the clock signal of the necleo.

I conclude that the fact of touching the pin creates a disturbance. But how to test if the quartz are active?

Sincerely

Antoine

Seb
ST Employee

A blanked flash STM32 was soldered on the PCB ?

If yes, the chip is in bootloader mode.

Do you see the oscillators running ?

Do you see noise on the MCU Vdd ?

Replace the Vdd to Vdda inductance by a 0 Ohm resistor. (increase the value if you need filtering)

Solder wires on the debug SWDIO/SWCLK/GND and check you can go debug mode/flash the chip from a debug probe such as the ST-Link.

Some STM32 needs precise clock for USB device mode to function properly.

JTP1
Lead

Try to pull PB2 down. It is Boot1 and should be low when entering system memory bootloader.

AD_716
Associate III

Hello, 

Thank you for your quick response

I just wired DM, DP, and BOOT. 

I removed the 0ohms resesitance that connected the V-Link clock to the MCU. I then installed a 8Mhz Quartz with 2 22Pf capacitors to do without the V-Link clock.

Then the STM on nucleo started in DFU mode, I was able to program it this way without any problem.

I reproduced my schematic identical to the nucleo, could I have made a mistake in the connection?

When I test the crystals on necleo, it goes into default when the tip of the oscilloscope touches the pin of the quartz. So I can't see the clock signal of the necleo.

I conclude that the fact of touching the pin creates a disturbance. But how to test if the quartz are active?

Sincerely

Antoine

AD_716
Associate III

Hello, 

Thank you for your reply 

I'll try but it seems surprising because on the nico PB2 is not connected to anything, not even to a pull-down resistor.

I also checked with the tester on the nucleo.

In the documentation, there is no BOOT 1 for the MCU LQFP64.

Only the LQFP48 which is the ST-Link has a PB2 pin (BOOT 1) which must be connected to ground.

In my case I don't use the ST-Link

Sincerely

Antoine

S.Ma
Principal

It is usually vital to have access to the debug/programming link of an STM32 on a board.

When using Nucleo, probably the code was debugged flashed and reflashed to a point that the initial blanked flash condition is gone, which is the custom board bringup situation.

Without debugger, finding the rootcause will consume more time.

Even if the SWD pins are used by application, you can still put a SW delay before overriding them, so you can catch the debug mode at power on.

AD_716
Associate III

You mean you have to flash the chip at least once via ST-Link before you can use the DFU?

The DFU mode is just to avoid using ST-Link?

You can also test to add 1.5k pullup to positive usb line even it is said not needed.