STM32F401 does not seem to boot on custom PCB!

[AD_716]

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

[LCE]

That is part of the basic clock setup, you should know where to find that and what it does.

If you did the clock setup with CubeMX, you could just search your source for "HAL_RCC_OscConfig".

[AD_716]

I don't need to configure the clock on NucleoF401.

I program on MBED and I use CubeProgrammer to inject the Code in DFU Mode.

On Nucleo no problem, I just connect the right pins and add an 8Mhz ocsillator with 2x22 pF

Thanks for your help

[AD_716]

I tried to power the MCU before the usb, but it doesn't change anything!

[AD_716]

Hello everyone, 

I have just done some additional testing.

1 - First of all, I took a new development card (Nucleo F401) to read with an oscilloscope the ocsillator. I detect a frequency at 7.9999 Mhz on X2 which is the LSE ocsilator.

The HSE is provided by ST-Link on this board.

2- On my initial development board, I cut the ST-Link board, add in X3 an 8Mhz ocsillator as recommended, add 2 resistors of 0 Ohms in R35 & R37, remove SB16, SB50, SB54, SB55 and add 2 condasators of 20pF in C33 & C34

I then connected USB_DP & USB_DM to a USB connector via 2 resistors of 22 Ohms, connected the +5V USB to the Vin of the Nucleo, set the jumperJP5 to position EV5, installed a momentary switch between the +3V3 and Pin 60 (BOOT 0).

When I press and hold BOOT, the Nucleo starts up in DFU mode and I can program it that way.

I measure on X2 (LSE) a frequency of 32Khz.

On X3 (HSE) I don't get any value but I read somewhere that this oscillator only clamps at startup.

The nico card starts well in DFU mode and everything works normally

3- On my custom card I don't read any frequency on X2 and X3. This means that the STM32 doesn't start! I checked all the power rails, the connections with the ocillators, the BOOT pins etc...

What do you think? Should I do a first programming with ST-Link? Has anyone ever mounted this MCU on a custom board& with DFU mode as programming mode?

I'll add the SWD pins to do other tests in the meantime

Thanks in advance for your help

Sincerely 

Antoine

[JTP1]

Hello Antoine

Note that F401 starts up allways with 16MHz RC oscillator. (you can refer stm32f401 datasheet chapter 3.11 clock and startup), and HSE is activated after software sets the right registers, in normal bootup. Now you have empty chip, HSE and also 32KHz LSE stays off, thats normal.

However, if the system bootloader is activated with BOOT0 and BOOT1, also the HSE oscillator is activated when bootloader tries to establish USB connection if USB is detected. (app note AN2606, cd00167594-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf).

So it seems that your problem is now in the USB detection phase or in actual HSE oscillator circuit.

You can check also an3156 to get better understanding about USB DFU connection.

Setting up SWD connection will certainly help you to debug problem, since you can then download programs and test for example that your oscillator circuit works. Who knows if there is for example wrong size capacitors on the 8MHz crystal installed and that is now preventing DFU USB connection since HSE is not working.

But USB DFU connection will also work with empty processors, it does not need any customer code to the flash. That is sure 

[AD_716]

Thank you very much for all this answer and the documents provided.

I found the problem! I had the MCU soldered by my supplier and it turns out after several searches with a magnifying glass that Flux or solder (not easy to see) made contact or behaved like a capacitor on pins 1 to 10 approximately...

So I put Flux, pass the soldering iron and clean with a special product to have a perfect solder!

Victory it works! The MCU connects in DFU mode! 

I will try to program it with a test code to see if everything is ok!

I will come back to you to keep you informed of the test.

Again a huge thank you to the community for your help and your reactivity

See you soon,

antoine

[AD_716 · Accepted solution]

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

[AD_716]

You are right!

Boot 1 must be linked to the ground but it is not so obvious, nucleo has a design error, see my explanation at the bottom of the post

Many thanks

Sincerely

Antoine

[JTP1]

Hello Antonie. Good that you finally found the root cause. Since most IO pins (including PB2) are floating during/after reset,even longer trace capacitance or leakage current on the Nucleo board can keep the level enough low so it boots in system memory boot space. I would not call it an error since Nucleo is not specified to demostrate USB DFU usage, it is just a general purpose development board.

Note also that it is enough to have pull down resistor on Boot1, and it can be still used as GPIO pin after reset. Boot pins are sampled in 4th Sysclk rising edge after reset.

Generally speaking, both of these boot pins could have weak internal pulldown, maybe so that it activates only short perioid of time after reset. That would save peoples lots of confusion :grinning_face_with_sweat:

[waclawek.jan]

Thanks for coming back with the solution.

This is a tricky issue indeed. I've posted an Idea to enhance the Nucleo boards. ST will ignore it as it does with most other Ideas, but it would be nice if we could upvote it beyond the 10-vote boundary.

JW