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]

Hi @RLanz.2​ 

Q1.1 will it wait infinitely?

R1.1 : Yes , according to the global sequence for the STM32 bootloader with FDCAN

Q1.2: How is it different from the bootloader path of execution when the bootloader

does not wait for any input and just continues to execute the application already

burnt to its flash?

R1.2 : Bootloader for STM632 with FDCAN have differente sequence

Regards

Diane

[Diane POMABIA]

Q2.1 I meant I was asking for an example to send a message in the opposite direction: via FDCAN from the host to the stm32 FDCAN bootloader - message id, and all its structure - even the most simple one. Can you provide me with such an example?

R 2.1 this Example send the message via FDCAN from host to the STM32

Regards

Diane

[Diane POMABIA]

Q3+4. Please let me explain what I meant: I am asking, after performing the jump to bootloader function from our SW running on the stm32, how can I check (using some outside tool the STM32CubeProgrammer?) to make sure that:

3+4.1 Is the FDCAN bootloader indeed STARTED to execute?

3+4.2 Is the FDCAN bootloader indeed WAITING for FDCAM message?

3+4.3 Is the FDCAN bootloader indeed WATING to ANY message in any other interface (and not the FDCAN)? If it somehow received a message in other interface (USART/I2C/SPI/DFU) and no longer waits to FDCAN message?

R3+4After sending the command, you must send the go command routine before moving to the address, but it is not possible to monitor the status in real time.

Regards

Diane

[RLanz.2]

Hi Diane POMABIA 

In the example you have attached, I see code pretty much similar to the code we use on our target STM32U575 (and not in the host).

1. Can you tell which host do you use to run this code, which is connected via FDCAN to STM32?
2. I find the following code lines confusing:

on one hand:

TxHeader.Identifier = 0x111;

and then on the other hand:

  TxHeader.Identifier = 0x02U; /* Get ID command opcode */

Can you review the code and comment if it should be changed?

Thank you

Roni

[RLanz.2]

Hi Diane POMABIA 

Can you please see the following order of operations:

A. I notice that the option bytes are not changed after restart (I observe this using the

STM32CubeProgrammer' reading the nSWBOOT0, nBOOT0), if in the jump to bootloader function, the HAL_RCC_DeInit() is performed BEFORE the HAL_FLASH_OB_Launch().

B. Only if the HAL_RCC_DeInit() is performed AFTER the HAL_FLASH_OB_Launch(),

then option bytes are changed according to the values for the bootloader to execute.

So, only when using option B, the option bytes are changed for correct values for the FDCAN bootloader to execute.

So my question is what is the correct order of operations, and why do I get such results?

Thanks

Roni