STM32U575 is memory remapping required - prior to jump to bootloader from application?

[RLanz.2]

In an earlier project based on STM32F7x,

we had to add memory remapping by hand:

SYSCFG->MEMRMP = 0x01;

There is no equivalent in SYSCFG for STMU575,

nor did I find relevant bits under SYSCFG->CFGR1 or CFGR1->CFGR2 or other field as part of SYSCFG.

[Diane POMABIA]

@RLanz.2​ ,

Exactly , you have also to add this condition.

Regards

Diane

[RLanz.2]

Ok, I understand.

And now, how does the bootloader "knows" it should wait and respond to a firmware update to be flashed into the STM32U575 flash,

or to just continue immediately to execute the application firmware already in the STM32U575 flash?

[Diane POMABIA]

Hi @RLanz.2​ 

I'm not sure I understand your question. Your question is if after executing the bootloader it will be able to switch to normal code?

Regards

Diane

[RLanz.2]

Hi
I want to understand how the (FDCAN) bootloader knows to "wait" for FDCAN communication from a host, to update(=write) a new software application to the STM32 CPU flash,
or to continue straight ahead and execute the software application already existing in the flash (as it is in a normal startup after powerup/reset)?
Thank you
Roni

[RLanz.2]

Hi

I want to understand how the (FDCAN) bootloader knows to "wait" for FDCAN communication from a host, to update(=write) a new software application to the STM32 CPU flash,

or to continue straight ahead and execute the software application already existing in the flash (as it is in a normal startup after powerup/reset)?

Thank you

[Diane POMABIA]

Hi @RLanz.2​ 

the bootloader is not able to know which feature will be used.

What happens is that it initializes all peripherals (SPI, USART, FDAN,... ).If it receives information about of pins linked to a peripheral it deinitializes the others.

2 ANs can help you to understand this procedure and which parameter to put to communicate with the good feature:

-AN2606 that describes the supported peripherals and hardware requirements to consider when using the bootloader of STM32 devices.

-AN5405 that describes the FDCAN protocol used in the STM32 microcontroller bootloader, providing details on each supported command.

Attention :

ST hosts: Host Hardware STLINK and SW STM32 hosts CubeProgrammer do not support FDCAN at this time.

Regards

Diane

[RLanz.2]

Hi

Thanks for your reply. In fact, I was actually already looking in those two ANs,

and unfortunately I still don't understand,

where it says in AN5405, in chapter 1 'Bootloader code sequence',

in Figure 1 'Bootloader for STM32 with FDCAN'

the initial state is 'Frame detected on FDCAN Rx pin'.

1. What ensures that the bootloader waits to any input (from FDCAN or SPI etc.) and does not continue to and execute the software application already existing in the flash (as it is in a normal startup after powerup/reset)?
2. Besides following the exact procedure to jump to boot, as you advised in our conversation above, what else is required to make sure the bootloader indeed "understands" it should wait and communicate via the FDCAN peripheral, and not other peripheral (SPI etc.)?
3. Is there any ST host supporting FDCAN? We currently use some other non-ST host to communicate with the STM32U575.

Thank you

Roni

[Diane POMABIA]

Hi @RLanz.2​ 

Q1 and Q2: It not possible for bootloader to Know what peripherals that will be use . Bootlaoder initializes all peripherals that are supported and their inputs. If bootloader detected communication on one input connected to a supported peripheral, Bootloader denitializes others peripherals (Refer to figure 1 of AN5405).

As long as the bootloader has not received a go cmd routine from host , you will remain stuck in the bootloader.

Q3: ST host (HW and SW) don't support FDCAN.

Regards

Diane

[GLASS]

Hi,@Diane POMABIA​ 

We currently​ eval opportunity to migrate designs with stm32l1 and stm32f429 to stm32u5. Can you confirm that remap CANNOT be made without writing to Option bytes?

Actually we write O.B.only ONCE during production.

We are affraid because we consider that option byte write can be corrupted (power loss or max write cycles) so we don't wants to brick products during USERS update.

They don't have access to Swd...

Tanks by advance​

[Diane POMABIA]

Hi @GLASS​ 

What do you want to say by "remap CANNOT be made without writing to Option bytes"?

Regards

Diane