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 ?

[Terry Barnaby]

Have just tried a NULEO-F756ZG board and as you say that works fine with the internal bootloader, at least on the USB_FS interface (haven't tried any serial ports). This has the CPU clocked from an external 8MHz source, so the bootloader, in general, appears to work with external clock sources. As expected this board raises the USB_FS D+ line even without any USB cable so that a host can detect its presence. In fact if I disable the external clock source so it has to use its HSI clock, it still puls the USB D+ line high although, as expected, it won't connect to the USB host. So the clock source should not affect the bootloader initialising the USB_FS device and setting USB_FS D+ high.

With the STM32F765 processor on our board and on the F769I-DISCO the USB_FS D+ line is never pulled high.

I would have thought that the F769I-DISCO should also boot from its USART1 via STLINK port as well. It just seems that there is an issue with the bootloader in these chips or some other configuration is needed to get them to work properly. Is there anyone at ST that can confirm what is happening here ?

[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!