Reply by Richard Damon●February 19, 20202020-02-19
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.
Reply by pozz●February 18, 20202020-02-18
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.
Reply by ●February 17, 20202020-02-17
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?
> 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.
Reply by pozz●February 3, 20202020-02-03
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?