Configuring USB port for DFU

[NSR]

When using the Nucleo board with the STM32H743 (Rev V) I can trigger a DFU event within software and using the STM32CubeProgrammer it can detect the presence of the board in DFU mode - so far so good. When using my own design (using a Rev Y part) I cannot seem to get the STM32CubeProgrammer to detect it.

In my design, I am using a regular USB type-B socket (the Nucleo uses a micro type-B), with USB_OTG_FS_DP and USB_OTG_FS_DM on PA12 and PA11 respectively; I have USB communications using the CDC, the same as how it was configured for the Nucleo board. Having read that the bootloader looks for the presence of the cable I've connected PA9 (USB_OTG_FS_VBUS) still to no avail. Is there something I'm missing?

Just to add, the routine I'm using to call the bootloader can be found at https://community.st.com/s/article/STM32H7-bootloader-jump-from-application

[Imen.D]

Hello @NSR​ ,

Make sure to use the latest release of STM32CubeProgrammer V2.7.0.

Have a look to this article and STM32CubeProgrammer 2.7.0 released to check if you have the same conditions as described in the "Fixed issues" section.

If the issue is encountred with the latest release, I suggest you to share the data log and .hex file. I will try to contact CubeProgrammer expert internally for help.

Imen

[NSR]

I don't think it's an issue with the programmer per se; I'm using version 2.3 of the programmer with the newer Rev V silicon fine (with device manager reporting the unit in DFU FS mode) whereas there's no change with our design using the older Rev Y silicon in the device manager.

[NSR]

Really struggling with this and getting mixed results with different devices and implementations.

Have obtained the bootloader ID from 0x1FF1E7FE I've collected the following results:

Our reference design using Nucleo Rev C ($AT1)

STM32H743ZIT6 Rev V - Bootloader ID: 0x90, listed as 0x90 in AN2606 rev. 47 (February 2021)

DFU via call to software function implementation: yes

VDD+BOOT0: yes

Our reference design using Nucleo Rev E ($AT2)

STM32H743ZIT6 Rev V - Bootloader ID: 0x90, listed as 0x90 in AN2606 rev. 47 (February 2021)

DFU via call to software function implementation: no

VDD+BOOT0: yes

Our design

STM32H743ZIT6 Rev Y - Bootloader ID: 0xD2, listed as 0xD2 in AN2606 rev. 34 (November 2018)

DFU via call to software function implementation: no

VDD+BOOT0: no

So not only are we facing difficulties with between the different revisions of the silicon but also the reference board.

Is there any documentation that described the differences between the $AT1 Rev C and $AT2 Rev E boards? Regarding the older Rev Y silicon in our design, I'm using the same software implementation across all devices and when trying the VDD+BOOT0 method I am (eventually) getting Unknown USB Device (Device Descriptor Request Failed) in Windows Device Manager. With the Nucleo boards and using VDD+BOOT0 (and software call on Rev C board) I get DFU in FS Mode. In our design, the BOOT0 pin is being pulled high via a 1K5 resistor from 3V3.

I am otherwise able to use the USB within my application as intended, via the CDC when I don't attempt to initiate DFU mode.

I would really like to put this down to the silicon but it appears there's something else afoot that needs attention.

[Javier1]

what about the XTAL?

DFU bootloader expects a specific value external HSE clock source.

Maybe the HSE in the nucleo boards is different than the one you used in your custom thing?

[NSR]

Hi Javier, thanks for taking the time to respond.

While I've read that if the USB is out with the clock timings that this can upset the process, I've not really read that much with the X3 XTAL. Reading p.24 of the user manual for the STM32H7 Nucleo-144 boards (MB1364, June 2020, UM2407 Rev 2), it states that HSE on-board oscillator from X3 crystal (not provided), which I've just verified is not fitted onto the Rev E board that I have to hand. There is the X2 LSE XTAL that is fitted, however. While I'm unable to get this particular board into DFU mode via the software function, I am able to achieve it by pulling the BOOT0 high by fitting a jumper across pins 5 (VDD) and 7 (BOOT0) on CN11.

[NSR]

Just to confirm that the X3 XTAL is also missing from the Rev C Nucleo board. While we've provisioned for the possibility of putting this part on our design, we've kept this consistent following the Nucleo examples and not populated.

Of further note, We are also running these boards (2x Nucleo and our design board) at 400 MHz, owing that this is the (supposedly) maximum speed of the Rev Y part; although we can get it running reliably at 480 MHz with all the peripherals running and USB in CDC mode, with the same application being uploaded consistently.