External crystal required for bootloader?

[GMeta.1]

Hi

There's a not-too-well worded paragraph from AN2606 on page 33:

For STM32 devices embedding bootloader using the DFU/CAN interface in which the
external clock source (HSE) is required for DFU/CAN operations, the detection of the HSE
value is done dynamically by the bootloader firmware and is based on the internal oscillator
clock (HSI, MSI). When (because of temperature variations or other conditions) the internal
oscillator precision is altered above the tolerance band (1% around the theoretical value),
the bootloader can calculate a wrong HSE frequency value. In this case, the bootloader
DFU/CAN interfaces can malfunction, or not work at all.

 Does this mean the bootloader requires an external oscillator when you are using USB with the bootloader? My circuit doesn't have an external crystal, for the application I am using HSI and everything is fine including using USB device (CDC). I'd be happy to just use USART1 as I am already using that in my application for debugging with an FTDI cable.

I am having trouble getting my STM32U073KCU6 to go into bootloader mode when I pull the BOOT0 pin HIGH. It doesn't seem to work even with USART1 even though I have pull-ups on the RX and TX lines. I am working from home and annoyingly I don't have my STLINK programmer so I can't check the option bytes to see if the register bits are good for 'pattern 15' which is what I need from AN2606. I haven't changed these bits and the factory reset for these bits would imply I just have to pull BOOT0 HIGH and reset.

[SofLit]

Hello,

According to AN2606, DFU is using HSI48 clock source, so no need for an external crystal:

It seems that the paragraph you mentioned is generic and it was inherited from older products like STM32F1.

[GMeta.1]

Yes I saw that too but was confused by that other paragraph. OK thanks. I shall wait until I can use a programmer to look at the option bits and hopefully that's what's stopping entering bootloader mode.

The flowchart in AN2606 shows that USART1 is checked first and USB is last. If there are pullups on the UART RX and TX pins, won't this mean the bootloader will always pick the UART even if there isn't a cable fitted? I'm just thinking ahead to when I sort out why the bootloader isn't running as ideally I'd like to use USB (DFU).

[SofLit]

---

@GMeta.1 wrote:

The flowchart in AN2606 shows that USART1 is checked first and USB is last. If there are pullups on the UART RX and TX pins, won't this mean the bootloader will always pick the UART even if there isn't a cable fitted? 

---

According the same application note, that doesn't depend on the HW detection on UART side but depends on if it was receiving a 0x7F:

[GMeta.1]

I managed to jury-rig an STLINK onto my board and I've checked the option bits:

BOOT_LOCK = 0 (unchecked)

BOOT0 pin = HIGH

nBOOT0 = 1 (checked)

nBOOT1 = 1 (checked)

nBOOT_SEL (checked)

As far as I can see this is enough for the device to enter bootloader mode? It clearly doesn't do this but jumps to flash and runs the app almost immediately regardless of anything connected to USART1 or USB.

I must be missing something. The fact that it doesn't even try to go into bootloader mode makes me thing there's another register setting somewhere.