cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F765 bootloader DFU boot with external oscillator

Terry Barnaby
Associate III

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 ?

13 REPLIES 13
Terry Barnaby
Associate III

Using a debugger via the SWD port the CPU is certainly in its bootloader with PC addresses in the range 0x1FFF0210 - 0x1FFF2C90.

I have also tried to access the boot loader using stm32flash over USART1, but this does not work either.

Any ideas on what may be happening and how to debug the bootloader ?

Is the code for the bootloader somewhere ?

Terry Barnaby
Associate III

Those addresses were actually 0x1FF00210 - 0x1FF02C90.

I have just tried to use the internal bootloader on an STM32F769I_DISCOVERY board. I linked across R19 (DNP resistor) to set BOOT0 high. Via the SWD interface I can see the CPU is running code in the internal bootloader. However again I cannot access the bootloader via USART1 (passes through on-board ST-LINK controller and USB). The USB_FS_DP, PA12 also remains low (I would have expected this to go high to indicate a USB device is present to the host).

Does the internal bootloader actually work on a STM32F769 ?

If it does will it work with an external HSE oscillator at 24 or 25 MHz ?

Any ideas ?

Terry Barnaby
Associate III

Anyone any ideas on this ?

Has anyone used the internal bootloader in a STM32F765, does it actually work ?

Definitely booted the F746G-DISCO into DFU mode, and I'm pretty sure the method also worked for the respondent, but I don't recall what F7 board they were using.

Earlier STM32 would benchmark the clock source, and needed some specific frequencies, seem to recall the F7 was less restrictive. NUCLEO boards typically get an 8 MHz signal applied to them rather than using a crystal directly attached.

The code to the boot loader is not furnished by ST, in situations I've needed it I generate an annotated listing.

Don't have anything here with a 24 MHz source. Might dig up an F769I-DISCO later.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Terry Barnaby
Associate III

Hi, thanks for the reply and info. Who is the respondent though ?

The AN2606 bootoader info states that the STM76xxx can use an HSE frequency between 4 and 26 MHz, but it does not mention external sources. So assuming it supports an external clock source it should work, or at least the USART1 should work as AN2606 says this uses the HSI clock. The USB_FS the D+ pin is not even being pulled high and I would have thought that would be done early on before the HSE is considered when a USB connection is determined.

I wonder if the bootloader has decided to boot from one of the multiple peripherals (including SPI), but I don't know how to determine that.

We have purchased a NUCLEO-F756ZG board which is simpler than the STM32F769I_DISCO to try that out to see if it helps with some ideas/info. (Note that the STM32F769I_DISCO has a USB_HS interface with external PHY so the bootloader DFU won't work with that, we use a scope to probe on the USB_FS PHY's D+ on that board and have tried the USART1 via the on-board STLINK).

Yes, may get down to disassembling the bootloader code, but i suspect that route will take some time to provide any results. Its probably die to some hardware on our board and the STM32F769I_DISCO, but never had this problem with other STM32 devices.

>>Who is the respondent though ?

The person who asked me the question, I talk to thousands of people, it's hard to keep track.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

https://community.st.com/s/question/0D50X00009XkXKUSA3/jump-to-internal-bootloader-with-stm32f7

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

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

There may be no easy way to tell a crystal from an [external] oscillator and I seriously doubt the bootloader accounts for the possibility of the oscillator. And, during the years, I have heard wildly differing reports of whether external oscillator works properly without HSE_BYPASS set or not. This is a long outstanding question, and I am not aware of a definitive answer.

I personally would assume the external oscillator for this particular purpose is a no-no.

JW

Most of the ones I have issue with HSE_BYPASS are L1/L0 series parts

Ok, so confirming the F769I-DISCO is problematic, it doesn't have a USB-FS port, and the VCP on USART1 is not viable, likely due to the number of pins on the device and their assorted states. The USART should auto-baud via a TIM measuring the 0x7F pattern.

I was able to use the USB-FS on the NUCLEO-F767ZI

0690X000006C0pQQAS.jpg

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..