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.

[GLASS]

Hi@Diane POMABIA​ , in your 1st reply you inform us that for Stm32U5 remap is not supported in SYSCFG register but only in Option Bytes.

We need to know if there is another way by direct access to a register​ because we do not want to rewrite option bytes in the field...(when products are in users hands;) )

Regards.​

[RLanz.2]

Hi Diane POMABIA (ST Employee),

In order to see which are the Rx and Tx pins for the FDCAN bootloader,

AN2606 says in section 75.1 for our MCU (STM32U575xx):

(FD)CAN RX is PB9

(FD)CAN TX is PB8

But STM32CubeIDE (.ioc) allows to configure (FD)CAN pins as follows:

(FD)CAN RX is PB8

(FD)CAN TX is PB9

Thus, opposite definitions of AN2606 documentation and STM32CubeIDE configuration tool.

Errata of our MCU (STM32U575xx) does not imply anything relevant.

Can you advise what is the correct configuration?

Thank you

Roni

[Diane POMABIA]

Hi @RLanz.2​ 

Thanks you for return . Correct configuration is :

(FD)CAN RX is PB8

(FD)CAN TX is PB9

 There is an error on AN2606. I escalate this error to concerned team that will correct this error for next revision.

Regards

Diane

[Diane POMABIA]

Hi @GLASS​ 

For security reasons, there is no other way.

Regards

Diane

[RLanz.2]

Hi Diane POMABIA

Thank you for this important info - we now take this into consideration in our HW layout, then I will update if you if it helped with the FDCAN bootloader too or ask for further help if required.

Thanks

Roni

[Diane POMABIA]

Hi @RLanz.2​ 

Thanks you for your feedback.

Regards

Diane

[RLanz.2]

Hi Diane POMABIA

Currently we have updated our HW layout accordingly to the correct configuration:

(FD)CAN RX is PB8

(FD)CAN TX is PB9

But still we cannot communicate with the FDCAN bootloader.

1. How long the FDCAN bootloader "waits" for some input in FDCAN Rx pin, before it continues execution and runs the already software burnt on STM32575 flash?
2. Can you specify the exact raw content of ANY command (like GetVersion or GetID) so I might try sending it repeatedly as a first try to cause the bootloader to get a message and wait for more FDCAN communication via FDCAN Rx pin?
3. Can we have any indication to use to be sure that the FDCAN bootloader indeed ENTERED execution following the procedure of jump_to_bootloader() as we discussed earlier (see above)?
4. Can I have any indication to use to be sure that the FDCAN bootloader indeed WAITING for any command or a go command, after it has ENTERED and started execution?
5. Back to the function of jump_to_bootloader() we have discussed above: the code to change the option bits is after HAL_RCC_DeInit() where I really loose debugger connection - it seems I cannot be sure the option bits are really changed, since after the execution of jump_to_bootloader(), debugger disconnected, and I connect with the STM32CubeProgrammer, and see that nSWBOOT0 and nBOOT0 were NOT changed. If I take the code to change option bits before HAL_RCC_DeInit(), then HAL_FLASH_OB_Launch() causes debugger to disconnet, and if I later connect with STM32CubeProgrammer, I see nSWBOOT0 and nBOOT0 ARE really changed, but I cannot be sure that the code after HAL_FLASH_OB_Launch() is really performed. So, what is really the correct order of operation inside function jump_to_bootloader()?

Thanks

Roni

[Diane POMABIA]

Hi @[RLanz.2] 

First of all, have you correctly configured your FDCAN? Can you confirm your configuration by looking at AN5405 page 3 (FDCAN settings)?

Note: To be accepted, MessageID and FilterID1 must match exactly.

To answer your question:

1: The FDCAN bootloader will "wait" for an input on the FDCAN Rx pin until it receives any information.

2: Yes of course, this code will help you to get the ID or version from the host.

/*******************************************************************************
 * Function Name  : HOST_FDCAN_GetIDCommand
 *******************************************************************************/
void HOST_FDCAN_GetIDCommand()
{
  FDCAN_TxHeaderTypeDef TxHeader;
 
  /* Prepare Tx Header */
  TxHeader.Identifier          = 0x111;
  TxHeader.IdType              = FDCAN_STANDARD_ID;
  TxHeader.TxFrameType         = FDCAN_DATA_FRAME;
  TxHeader.DataLength          = FDCAN_DLC_BYTES_64;
  TxHeader.ErrorStateIndicator = FDCAN_ESI_ACTIVE;
  TxHeader.BitRateSwitch       = FDCAN_BRS_ON;
  TxHeader.FDFormat            = FDCAN_FD_CAN;
  TxHeader.TxEventFifoControl  = FDCAN_NO_TX_EVENTS;
  TxHeader.MessageMarker       = 0;
 
  TxHeader.Identifier          = 0x02U; /* Get ID command opcode */
 
  HAL_FDCAN_AddMessageToTxFifoQ(&hfdcan, &TxHeader, &TxData[0]);
 
  /* check if FIFO 0 receive at least one message */
  while (HAL_FDCAN_GetRxFifoFillLevel(&hfdcan, FDCAN_RX_FIFO0) < 1) {;}
  HAL_FDCAN_GetRxMessage(&hfdcan, FDCAN_RX_FIFO0, &RxHeader, &RxData[0]);
 
  /* check if FIFO 0 receive at least one message */
  while (HAL_FDCAN_GetRxFifoFillLevel(&hfdcan, FDCAN_RX_FIFO0) < 1) {;}
  HAL_FDCAN_GetRxMessage(&hfdcan, FDCAN_RX_FIFO0, &RxHeader, &RxData[1]);
 
  /* check if FIFO 0 receive at least one message */
  while (HAL_FDCAN_GetRxFifoFillLevel(&hfdcan, FDCAN_RX_FIFO0) < 1) {;}
  HAL_FDCAN_GetRxMessage(&hfdcan, FDCAN_RX_FIFO0, &RxHeader, &RxData[3]);
}

3 and 4: if you have send an command and you don't receive respond , you have not connected .

Regards

Diane

[Diane POMABIA]

@RLanz.2​ 

For 5 :

if i refer to last code , if the RCC denit placed after HAL_FLASH_OB_Launch(), will not be executed unless you do not fit into this condition "if (Nboot0_OB!=OB_NBOOT0_RESET || TZEN_OB !=OB_TZEN_DISABLE ||NSWBoot0_OB !=OB_BOOT0_FROM_OB)".

You have to place RCC denit before HAL_FLASH_OB_Launch().

Regards

Diane

[RLanz.2]

Hi Diane POMABIA (ST Employee)

Your starting remarks:

First of all, have you correctly configured your FDCAN? Can you confirm your configuration by looking at AN5405 page 3 (FDCAN settings)?

Note: To be accepted, MessageID and FilterID1 must match exactly.

I mean host side TBD target side TBD

My response:

The stm32 FDCAN bootloader (which is fixed and cannot be accessed/changed) is supposed to have the correct configuration.

In my trials to verify host is ok to communicate in FDCAN with the stm32, I use our nominal application which executes on the stm32, to switch to FDCAN using the same settings as the FDCAN bootloader (as specified also in AN5405).

So, can you clarify and explain your recommendation and remark?

1. The FDCAN bootloader will "wait" for an input on the FDCAN Rx pin until it receives any information:

1.1 will it wait infinitely?

1.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?

2.

2.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?

2.2 With regard to this example on how to send a message via FDCAN to host - I can still benefit from it: I will try using this example to send from our application (and not the bootloader, which its code I cannot change of course) to check the host side. But 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?

Can you send an operational working version of the code?

 3+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?

5 I see 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(). 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.

Thanks

Roni