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.

[mƎALLEm]

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).

[mƎALLEm]

---

@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.

[GMeta.1]

After playing around a bit I have managed to get it into bootloader mode but only after flashing some of the option bits:

This works:

BOOT_LOCK = 0 (unchecked)

BOOT0 pin = HIGH

nBOOT0 = 0 (unchecked)

nBOOT1 = 1 (checked)

nBOOT_SEL = 0 (unchecked)

This is little like the second option of pattern 15 except that I still have to boot up with BOOT0 HIGH but pattern 15 in AN2606 doesn't mention this so I assumed it doesn't care about the state of BOOT0?

[GMeta.1]

OK. Have finally understood this now thanks to RM0503 table 6 (above).

 

Since nBOOT_SEL and nBOOT0 are 1 by factory default the device will always boot into main flash regardless of BOOT0 pin. If you want to be able to use BOOT0 to enter bootloader mode then you will have to initially connect a programmer to change the above bits in the user configuration register. Because you probably don't want the device to directly boot into the bootloader every time, then you'll want the second row down which means nBOOT1 = 1 and nBOOT_SEL = 0. Now when you set BOOT0 HIGH on power-up or reset, it will enter bootloader mode.

This makes me think pattern 15 isn't correct for the STM32U0 device in AN2606.

[Shirley.Ye]

Hello,

 

in the AN2606, there is nBoot0_SW(bit).

and seems in your case, the nBoot0_SW(bit)= ~nBOOT_SEL.

 

you can consider the  nBoot0_SW as a selection to choose boot0(pin) effective or nboot0(bit) effective.