Can't seem to get into the System Bootloader of a STM32F745

I can only suggest issues, I have never used the bootloader.

did you check the required baud rate for the boot loader ?

how does the bootloader come to a baud rate ?

I always install the 6pin SWD connector, do you have that on the board ?

Likely half a dozen other pins that need to remain stable.

Breaking execution in a debugger should be able to show it is in ROM

BOOT1 doing what?

USART3 PB10/PB11 tested in normal operation? 9600 8E1 for boot loader

Having you tried calling the loader from you app, does it work/function in that mode?

If connecting via USB does it come up in "STM32 Device in DFU Mode" when BOOT0 pulled-high and powered up?

For those interested in ST bootloaders, please refer to AN2606.

I do have an SWD connecter, but only on a couple of boards for development; on regular boards in production, the SWD/JTAG will not be populated (sparing every cent!), therefore the plan is to flash the devices using the internal bootlader.

The other pins involved in the bootloader do not need to remain stable, as the bootloader loops through all potential sources of data, except the USB, which, if it finds active, remains there and never returns (see AN2606). But the USB pins are now floating, and still no luck. Unfortunately, I can't use the USB for booting, as there is no USB connector on these pins (normally USB is used internally to connect to an LTE modem).

BOOT1 does not exist on this uC variant. The USART3 is not used on board, the pins are simply routed to an expansion connector. There are no other pull-ups/downs on them, nothing.

The bootloader does not have a specific speed, it autobauds on the 0x7F. Normally it is used at 115200, but it can go even higher than that (when it works! e.g. on other boards I did, with SM32F427). On 9600 Baud it would take an eternity to load say, 600K of code.

I didn't try to call the bootloader myself, probably it would work, but it would not help anyway. I need it when the controllers are empty (and I don't believe ST forgot to flash it in its place ;-).

However, what I will do, and that's a good idea, I will check with the debugger where the uC is spending his time when it should be in the bootloader.

on my boards I use a 6 x 2.54mm array of holes for the SWD.

my programmer pins slot into the holes for programming.

Indeed, the debugger shows the uC wandering somewhere around 0x33000000, which obviously is not in the bootloader. The problem seems to be the two BOOT_ADDx option bytes. They should be loaded with 0x0040, but on my particular board they seem to be erased (0xFFFF). It's true that this is a development board, that has seen a lot of experiments (including firmware updates over LTE) but I wonder how comes that this register has been erased. I never touched any option bits.