Power cycle required to enter DFU

[mjuels]

I am working on a board containing two STM32F412, and I am having a hard time reaching the DFU bootloader:

• If I power off the board, pull the boot pin low, and then power on the board directly via USB, then cubeProgrammer is able to connect to the bootloader via DFU, completely as expected
• However, if I let the board be powered in run-mode, pull the boot pin low, and then reset the MCU via the nRST pin, then the cubeProgrammer is not able to connect the bootloader via DFU
  •  At this point I am able to keep the boot pin grounded, power cycle the board (by disconnect/reconnecting the USB cable), and then cubeprogrammer is able to connect to the bootloader again

The schematic is illustrated below:

• SW3 is a latching switch to select which of the two MCUs are connected to the USB connector
• USB1.D- and USB1.D+ goes to PA11 and PA12, respectively on the first MCU, and USB2.D- and USB2.D+ and similarly connected to the second MCU
• The design relies on the internal MCU pull-up resistors of the D+ line, as described on AN2606 (Table 72)

The reset and boot pin schematic is illustrated below:

• The NRST signal is jointly connected to the reset pin on both MCUs
• SW2 is switch that jointly asserts the boot pin on each MCU - Boot0_1 and Boot0_2 goes to Boot0 on MCU 1 and 2 respectively

The schematic is fully consistent with the design we usually use without issues, except for the details relating to having two MCUs instead of only one.

Any suggestions as to what might cause the issue we are seeing would be greatly appreciated.  

[STOne-32]

Dear @mjuels ,

in case of using one single MCU on same board it should have the same behavior also ?

As here the Board is bus powered it is a bit tricky as not sure that System reset using NRST pin is able to reset the USB Embedded PHY . If the board is no bus  powered , just unplugging and repluging the usb cable should work ? If you can try it .

Hope it helps ,

STOne-32

[mjuels]

Hello @STOne-32 ,

Thank you for your reply, although I am not certain I understand - Can you elaborate what you suggest I should try?

To elaborate on my issue:

• My board can be powered either by a 24V supply, or directly by USB cable 
  • In the description the description above, the board was only powered from a USB cable
•  The presented circuit for resetting the MCU is used with great success on many of our other boards for entering DFU mode without doing a full power-on reset of the board 

You mention that the USB PHY might not fulle reset with the NRST reset - Is there a better way to conduct a reset, or something else I could try?

Best regards

[mjuels]

Hello @STOne-32 ,

I think I maybe understood your suggestion:

• Before powering on the board, I grounded the boot pin (and left it grounded for all of the following)
• I then powered the board via a 24V external supply
• I attached the USB cable
• -> CubeProgrammer connects to bootloader DFU as expected
• I press the reset button to ground the NRST pin
• -> CubeProgrammer looses connection to DFU
• I unplug the USB cable and reconnect it
• -> CubeProgrammer still cannot connect to DFU
• I unplug the cable, and turn of the power supply
• Then I turn on the power supply and reconnect the USB cable
• -> CubeProgrammer connects to bootloader DFU as expected

So as you suggested, it seems that the issue lies not with the USB connection via the cable, but the internal reset of the USB phy.

What can be done to fix this - I have measured the NRST pin with an oscilloscope when the reset button is pressed, and it does go to 0V, which it what we usually do, so I am not sure what may be preventing the reset in this board?

[mjuels]

Hello @STOne-32 ,

I saw you added a kudo but no remark om the issue:

• Do you have any suggestions on why the NRST does not reset the USB phy?

We have used the same STM32F412 on other boards where this issue does not occur

I have measured that the NRST is in fact pulled low when i press the button, so I dont know why it wouldnt work

[mjuels · Accepted solution]

I figured it out.

I had forgotten that BOOT1 is a physical pin on the F412 (PB2) - I had left it floating in my design, so the wrong boot mode is selected.

If I manually ground PB2 with a jumperwire during reset, the correct bootmode is selected, and the DFU kan be reached as intended.