Forums

STM32L4R9 native bootloader (system memory)

Started by pozz February 3, 2020
I have a board that mounts STM32L4R9 MCU. I'm interested in the native 
USB bootloader, the one that resides in system memory.

The BOOT0 pin can be pulled-down or pulled-up by resistors, but those 
resistors can't be moved (soldered/unsoldered) at every upgrade.

What I'd like to do is:

- at startup, if a USB cable is connected, system memory should be 
selected as boot memory area
- at startup, if no USB cable is connected, main Flash should be 
selected as boot memory area

Unfortunately this isn't how it works. I see that boot memory area is 
selected by BOOT0 pin and some options bytes.

If I fix BOOT0 to GND, Main Flash is selected if it isn't empty. So it 
can't be used for upgrade, but only for first programming (when Main 
Flash is empty).

If I set nSWBOOT0 to 0, system memory is always selected at startup. 
However the bootloader seems block, even if no USB cable is connected, 
so the application will not ever launched.

I think the only solutions is to change the PCB (and use a jumper to 
select Main or system memory) or to implement a custom USB bootloader 
that exits automatically after a timeout.
In the latter case, do you know if ST USB DFU bootloader source code is 
publicly available?
On 2020-02-03 pozz wrote in comp.arch.embedded:
> I have a board that mounts STM32L4R9 MCU. I'm interested in the native > USB bootloader, the one that resides in system memory. > > The BOOT0 pin can be pulled-down or pulled-up by resistors, but those > resistors can't be moved (soldered/unsoldered) at every upgrade. > > What I'd like to do is: > > - at startup, if a USB cable is connected, system memory should be > selected as boot memory area > - at startup, if no USB cable is connected, main Flash should be > selected as boot memory area > > Unfortunately this isn't how it works. I see that boot memory area is > selected by BOOT0 pin and some options bytes. > > If I fix BOOT0 to GND, Main Flash is selected if it isn't empty. So it > can't be used for upgrade, but only for first programming (when Main > Flash is empty). > > If I set nSWBOOT0 to 0, system memory is always selected at startup. > However the bootloader seems block, even if no USB cable is connected, > so the application will not ever launched. > > I think the only solutions is to change the PCB (and use a jumper to > select Main or system memory) or to implement a custom USB bootloader > that exits automatically after a timeout. > In the latter case, do you know if ST USB DFU bootloader source code is > publicly available?
If you change the hardware, you could also let BOOT0 level depend on USB connected or not. Then you can automatically boot from system memory when a USB is connected and start up normally when, not without moving a jumper. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Beware of a tall blond man with one black shoe.
mandag den 3. februar 2020 kl. 10.05.57 UTC+1 skrev pozz:
> I have a board that mounts STM32L4R9 MCU. I'm interested in the native > USB bootloader, the one that resides in system memory. > > The BOOT0 pin can be pulled-down or pulled-up by resistors, but those > resistors can't be moved (soldered/unsoldered) at every upgrade. > > What I'd like to do is: > > - at startup, if a USB cable is connected, system memory should be > selected as boot memory area > - at startup, if no USB cable is connected, main Flash should be > selected as boot memory area > > Unfortunately this isn't how it works. I see that boot memory area is > selected by BOOT0 pin and some options bytes. > > If I fix BOOT0 to GND, Main Flash is selected if it isn't empty. So it > can't be used for upgrade, but only for first programming (when Main > Flash is empty). > > If I set nSWBOOT0 to 0, system memory is always selected at startup. > However the bootloader seems block, even if no USB cable is connected, > so the application will not ever launched. > > I think the only solutions is to change the PCB (and use a jumper to > select Main or system memory) or to implement a custom USB bootloader > that exits automatically after a timeout. > In the latter case, do you know if ST USB DFU bootloader source code is > publicly available?
it is possible to jump to the native bootloader from an application https://stm32f4-discovery.net/2017/04/tutorial-jump-system-memory-software-stm32/
Il 18/02/2020 03:43, lasselangwadtchristensen@gmail.com ha scritto:
> mandag den 3. februar 2020 kl. 10.05.57 UTC+1 skrev pozz: >> I have a board that mounts STM32L4R9 MCU. I'm interested in the native >> USB bootloader, the one that resides in system memory. >> >> The BOOT0 pin can be pulled-down or pulled-up by resistors, but those >> resistors can't be moved (soldered/unsoldered) at every upgrade. >> >> What I'd like to do is: >> >> - at startup, if a USB cable is connected, system memory should be >> selected as boot memory area >> - at startup, if no USB cable is connected, main Flash should be >> selected as boot memory area >> >> Unfortunately this isn't how it works. I see that boot memory area is >> selected by BOOT0 pin and some options bytes. >> >> If I fix BOOT0 to GND, Main Flash is selected if it isn't empty. So it >> can't be used for upgrade, but only for first programming (when Main >> Flash is empty). >> >> If I set nSWBOOT0 to 0, system memory is always selected at startup. >> However the bootloader seems block, even if no USB cable is connected, >> so the application will not ever launched. >> >> I think the only solutions is to change the PCB (and use a jumper to >> select Main or system memory) or to implement a custom USB bootloader >> that exits automatically after a timeout. >> In the latter case, do you know if ST USB DFU bootloader source code is >> publicly available? > > it is possible to jump to the native bootloader from an application > > > https://stm32f4-discovery.net/2017/04/tutorial-jump-system-memory-software-stm32/
Yes, but you need to have an application already written and the application shouldn't have any bugs that prevent going to the bootloader for upgrade. Moreover, after reading comments, it seems this doesn't work well for USB, but only for the UART.
On 2/18/20 9:59 AM, pozz wrote:
> Il 18/02/2020 03:43, lasselangwadtchristensen@gmail.com ha scritto: >> mandag den 3. februar 2020 kl. 10.05.57 UTC+1 skrev pozz: >>> I have a board that mounts STM32L4R9 MCU. I'm interested in the native >>> USB bootloader, the one that resides in system memory. >>> >>> The BOOT0 pin can be pulled-down or pulled-up by resistors, but those >>> resistors can't be moved (soldered/unsoldered) at every upgrade. >>> >>> What I'd like to do is: >>> >>> - at startup, if a USB cable is connected, system memory should be >>> selected as boot memory area >>> - at startup, if no USB cable is connected, main Flash should be >>> selected as boot memory area >>> >>> Unfortunately this isn't how it works. I see that boot memory area is >>> selected by BOOT0 pin and some options bytes. >>> >>> If I fix BOOT0 to GND, Main Flash is selected if it isn't empty. So it >>> can't be used for upgrade, but only for first programming (when Main >>> Flash is empty). >>> >>> If I set nSWBOOT0 to 0, system memory is always selected at startup. >>> However the bootloader seems block, even if no USB cable is connected, >>> so the application will not ever launched. >>> >>> I think the only solutions is to change the PCB (and use a jumper to >>> select Main or system memory) or to implement a custom USB bootloader >>> that exits automatically after a timeout. >>> In the latter case, do you know if ST USB DFU bootloader source code is >>> publicly available? >> >> it is possible to jump to the native bootloader from an application >> >> >> https://stm32f4-discovery.net/2017/04/tutorial-jump-system-memory-software-stm32/ >> > > Yes, but you need to have an application already written and the > application shouldn't have any bugs that prevent going to the bootloader > for upgrade. > > Moreover, after reading comments, it seems this doesn't work well for > USB, but only for the UART. > >
Yes, for development work, especially to get your code to enter boot-loading mode, or to handle system crashes, you need somethin better, but for that you likely want a full debugger interface anyway. The jump to boot-loader mode does make a simple interface to allow 'field upgrade' to production systems.