STM32F765 bootloader DFU boot with external oscillator

[Terry Barnaby]

We have a newly designed board that uses an STM32F765 up and running. However with the BOOT0 line held high it does not present a DFU interface on the USB_FS port. The USB_FS_DP line remains low. We can run suitable USB_FS code on the STM32F765 and the USB_FS interface works fine. We are trying to debug why the bootloader does not work with the DFU.

One thing this board has, that our previous STM32F4 boards don't have, is an external 24 MHz oscillator rather than a 16 MHz crystal on the HSE. (It also has a separate USB_HS PHY to another USB port).

We have also tried accessing the bootloader via USART1, this also does not work.

1. Does anyone know if the STM32F7 bootloader will perform a DFU boot with an external oscillator rather than a crystal on the HSE ?

2. All of the other bootloader boot sources should have lines pulled low. Any ideas on what may be going wrong and how to debug this ?

[Tesla DeLorean]

The F769I-DISCO has a huge BGA and the board is very busy. Doesn't look like it's been built with much accommodation to pull BOOT0 high or affording access to the System Loader. You could review the circuit connectivity in the context of the App Note, but it's a lot of work.

>>Is there anyone at ST that can confirm what is happening here ?

Try the FAE assigned to your account, or at the local sales office. Alternately file an online support request on ST.COM

[Terry Barnaby]

We have now fixed this with help from Neil Dewey of Avnet who communicated with ST support.

There is a bug/feature in the STM32F769 internal bootloader code to do with booting from SPI interfaces. Our board has an USB_HS interface as well as a USB_FS interface. The USB-HS ULPI PHY, USB3320, presents a ULPI clock on the CPU's A5 pin. As well as being used for an USB_HS interface A5 is also a SPI clock line on one of the SPI devices the CPU can boot from. Although the bootloaders SPI documentation, AN4286, states that the SPI devices are looking for a data value of 0x5A it appears that even a clock on one of the bootloader SPI interface's clock lines is enough to stop the bootloader trying any other boot device. I presume any STM32 that supports booting from SPI interfaces will have this issue.

To get around the issue we have pulled the ULPI PHY's nReset line low by default. This disables the ULPI_CLK to A5. The STM32F769 now presents a DFU interface on the USB_FS pins and all works fine. Our program when running can pull the ULPI PHY's nReset line high to activate the USB_HS interface.

I do consider this a bug rather than a feature that really should be fixed in the bootloader. At least the documentation AN2606 and/or the AN4286 SPI bootloader documentation should make it clear that if there is a clock like signal on the SPI clock lines the bootloader will not try and boot from any other device and this is irrespective of any SPI data value. Is it possible to feed that back somehow ?

Terry

[zoompig]

Thanks for posting that, Terry B. We had the exact same issue with an STM32F767 and the USB3320 PHY, and this thread helped me find the problem.

Since we used the on-board ST USB pins for something else, (In our case, some on-board power management) I had to also disconnect PA12, which the bootloader thinks is USB D+. It drives this pin in an effort to detect a DFU connection.

I guess the moral of the story is: Watch out for those pins the ST bootloader assumes are a dedicated peripheral, when your board and end application may use this pins as something else!