Are there any known issues with the system bootloader for the STM32L4S5VI?

[smitty.werberjagermanjensen]

Rev 6 of the errata document, section 2.2.13, states the following:

The bootloader might not work on STM32L4RxxG/SxxG 1-Mbyte part number devices with date code week 04 2020 or earlier. This depends on the device bootloader version (V9.2 is not functional). In order to check whether the device has the fixed bootloader version or not, perform a read at address 0x1FFF 6FFE:

• If the read value is 0x92 then the version is V9.2 and the device has the non-functional bootloader.

• If the read value is 0x95 then the version is V9.5 and the device has the fixed bootloader.

Key Points:

• Our bootloader version is reading as 0x92.
• Our part is a 2MB part so it shouldn't be falling under the errata.
• The behaviour we're seeing looks to us like it's related to the errata, hence this question.
• BOOT0 pin is pulled low
• nBOOT0, nBOOT1, and nSWBOOT0 are all set to 1.

More Detail:

We've implemented a bootloader that basically ping-pongs between banks, logic as follows:

• Erase "other" bank.
• Program application image into "other" bank.
• Toggle BFB2 bit.
• Reboot (to begin running the application we just programmed into the other bank).

Occasionally (very few occasions), we're seeing that when the "other" bank is Bank 2, i.e. we're booting with BFB2 set, the system will not boot into our application, and will instead remain stuck in the system bootloader code where it seems to be waiting for some code to download.

Are there other issues possibly lurking in the bootloader? Is there something else we could be checking?

[JFieb]

Smitty,

We have this issue on the STM32L4Rxx MCU (with 2MB flash). Oddly, the boot from Bank 2 option (BFB2) only works when Bank 1 is *also* programmed. Our boot pins/registers are as you described.

We've actually narrowed the requirement down to just programming any value in the first long word of Bank 1. For example, erasing all of Bank 1 and only programming 0xFFFFFE at the start address, allows the BFB2 configuration to work correctly.

We do have the 'bad' MCU revision (Rev Y) described in the STM32L4Rxxx and STML4Sxxx Errata, (2.2.13) but this specifically calls out only the 1MB parts. [We have ordered the Rev W MCUs to see if this also fixes the 2MB parts].

It's very repeatable for us -- A reboot with Bank 1 erased will remain forever in the ST Embedded Bootloader (System Memory 0x1FF00000+) and even though BFB2 is set, the MCU will never reach the valid code in Bank 2 . :confounded_face: :confounded_face: :confounded_face:

The behaviour we are seeing does NOT match the documented boot process (shown below) -- the content of Bank 1 should not be a factor when BFB2 is set (and Bank 2 is valid).

I'm really hoping an ST guru can confirm this is an issue in the Rev Y MCUs and -- fingers crossed -- not an issue in the Rev W MCUs.

Anyone in the community (ST or otherwise) have a clever work-around? Unfortunately for us, erasing Bank 1 is unavoidable at some point.

cheers,

+Joel.

[Amel NASRI]

Hello @smitty.werberjagermanjensen​  & @JFieb​ ,

First of all, I would like to confirm that the described limitation is applicable only for 1MB devices. So even if your bootloader version of the 2MB device is 9.2, the described limitation is not applicable.

Then, I want to confirm that what you see as behaviour is totally aligned with specification (reference manual).

In RM0432, we describe the usage of BFB2 as following:

To select boot from Flash memory bank 2, set the BFB2 bit in the user option bytes. When

this bit is set and the boot pins are in the boot from main Flash memory configuration, the

device boots from system memory, and the boot loader jumps to execute the user

application programmed in Flash memory bank 2. 

The boot pins configuration is described in "Table 4. Boot modes":

The explanation of what you see is in the note of this table. That is why you boot as expected from Bank2 if you write something on Bank1.

So, if BOOT0 is pulled low and Main Flash is empty, you will boot from System memory (as shown in line 2 of the table).

You can force boot from main flash memory in such case if you clear the PEMPTY bit (FLASH_SR register).

If BFB2 is set, you can boot from bank2 in case nSWBOOT0 = 0 and nBOOT0 = 1 whatever is the status of PEMPTY.

I agree with you that "Figure 81. Dual bank boot implementation for STM32L4Rxxx/STM32L4Sxxx bootloader V9.x" of AN2606 needs to be reviewed.

-Amel