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

[ONadr.1]

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

[AD_716]

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]

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.

[AD_716]

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

[JTP1]

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

[AD_716]

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

[JTP1]

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

[S.Ma]

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]

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?

[LCE]

You have not yet answered the important question:

Have you changed the firmware, so that "HSE" is used with a quartz, not an oscillator.

So you have to set:

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE | RCC_OSCILLATORTYPE_LSE;

RCC_OscInitStruct.HSEState = RCC_HSE_ON; // not RCC_HSE_BYPASS

RCC_OscInitStruct.LSEState = RCC_LSE_ON;

You should always keep the SWD pins, for debugging and flashing with STlink.

Especially on your first board...

[AD_716]

Hello,

Thank you for your answer,

As I don't have access to the DFU, it is impossible for me to modify the firmware (on my custom card).

I will resolder some wires to access the SWD pin and try to program via ST-Link.

Where do I put the lines of code you provided?

[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".

[ONadr.1]

Also, the MCU may be in a Hard Fault state because the external oscillator does not start at the given time. The only way is to connect the STLink from the Nucleo board and see what happens.

[AD_716]

Yes I will add wires to access the SWD. I finish a spot for work and I put glue...

Thanks for the info!

[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