STM32L071KZ MCU Flash Issue over ST bootloader

[Koil Arul Raj.S]

We are currently working on flashing an STM32L071KZ MCU using the STM32 bootloader.

The flashing process completes successfully when using a 64-byte payload. However, when we reduce the payload size to 8, 16, or 32 bytes, we observe unexpected behavior. In each case, only the first 8, 16, or 32 bytes of every 64-byte flash block are programmed successfully, while the remaining writes within the same 64-byte block do not take effect. This pattern repeats consistently for every subsequent 64-byte-aligned address.

We have verified that:

1. The correct data is being transmitted to the MCU.
2. The target flash address is incremented correctly for each write operation.
3. The bootloader acknowledges the write commands.

Despite this, the flash programming behaves correctly only when using a 64-byte payload.

Is there any known limitation or programming requirement for the STM32L071KZ bootloader or flash controller regarding payload sizes? Are there any additional steps or constraints that must be followed when programming the flash using payloads smaller than 64 bytes?

Do we need to set any configuration in the keil software to support other size payload while flashing?

Any guidance or insights would be greatly appreciated.

 

Thank you.

[Pavel A.]

Do you use the ST HAL library to program the flash? If yes: the HAL_FLASH_Program function accepts only 4-byte payload, so it’s not clear how you program other sizes.

https://github.com/STMicroelectronics/stm32l0xx-hal-driver/blob/9f614d91f5a4aa094a86c7ee3ca9292e8492f2c0/Src/stm32l0xx_hal_flash.c#L228

However, STM32L0 has a “multiple” programming mode that programs by chunks of exactly 64 bytes - but this mode is off after reset, and the current STM32L0 HAL library doesn't seem to implement it.

Looks like you’ve activated it somehow.

( see RM0377, 3.3.4)

UPDATE:

Sorry so you’re using the built-in ST bootloader. Then again, it looks like the “multiple” mode activates somehow. If this behavior is stable (always reproduces) - just keep programming by 64 bytes?

 

[Koil Arul Raj.S]

Hi ​@Pavel A. 

Thanks for your response. Is there any way to configure mode in bootloader?
We didn’t activate any specific mode during our flashing. Is this factory made setting in the MCU series?

 

Looking forward for your response.

 

Thank you.

[Pavel A.]

​@Koil Arul Raj.S 

I don’t have a L0 board to test; hopefully ​@mƎALLEm can resolve the riddle.🙏

[TDK]

It should work. Which bootloader are you using (UART, SPI, I2C, USB DFU, etc)? Which program is being used to communicate with it?

[Koil Arul Raj.S]

Hi ​@TDK,

Thanks for your response. We are using bootloader commands via I2C to program the flash. Is there any additional configuration needed to flash different payloads.

 

Thank you.

 

[mƎALLEm]

Hello ​@Koil Arul Raj.S and welcome to the ST community,

Could you please provide the command sequence you are performing during this process?

[LCE]

I have decided against the internal STM32 bootloader, it’s too much of a black box.

For flash update i only use “half pages”, which has a size of 64 bytes = 16 words, not the seemingly possible word size.

Edit: I’m using the L073 

[rich.g.williams]

​@Koil Arul Raj.S  ​@LCE   

There is an easy workaround for all your problems to using the bootloader as follows:-

1. Program in 256 byte blocks always 
2. Put your data at the front of the block, if only 8 bytes arrange them from 0x00 to 0x07 and pad 0x08 to 0x255 with 0xFF
3. When you program the bootloader will give the instructions to program the 256 byte block but the 0xFF padding will do nothing 
4. For your next small record just move the start of programming address on by your record length

Only your data at the front of the 256 byte block will do anything.

The basis for this is that Erasing wears flash but programming does not.

The ST Bootloader works fine 100% for me. 

[LCE]

As I said, I want and need more control, and there were some things I did not like about the ST bootloader.

Just found my notes - this should not keep others from using the internal BL - but it’s not for us!:

 

With all the info, having checked all documentation, decision against the system bootloader.

Reasons for that:

• Interface 1): the L07x / L08x  devices we'll probably use have only UART bootloaders - which doesn't really fit into the design, as the main communication between base / modules will be via I2C. And "clocked" interfaces are prefered anyway (and don't want to have baud rate troubles or scale down below 115k2).
• Interface 2): the interface scanning, we'll have different modules in the system and on the same bus, and it might be too much trouble keeping the unused IOs quiet.
• Debugging: a self-made bootloader will give the opportunity for debugging via UART, and / or at least LEDs.
• Documentation: is still a little bit lacking, or distributed among too many documents. And we don't want "black boxes" in the system.
• We have enough experience writing the bootloader, re-using lots of stuff that we already have (BL for H7, many AVRs).

 

[rich.g.williams]

hi ​@LCE  I agree with you entirely. I did not intend to conflict.

The ST Bootloader is fine as an emergency fallback, I can pull BOOT0 high and the Bootloader is there.  

What happens is that occasionally I write something slightly new, put it in flash, and it crashes (mistake in my code). That’s when the Bootloader is useful. Same for a production environment I suppose - ST Bootloader last resort to recover previous flash image.

Your first point I agree 100% SPI or I2C is ideal, 16 bit clocked, like shift register, deterministically shift words into and out of target device - gold standard for provisioning. I have also used CAN, very reliable ideal if target is in-situ and already on a busy industrial or automotive CAN (or FDCAN) bus.

Second item I2C ideal for this, CAN also ideal if you already use CAN bus.

Third item debugging, I have used the ST Bootloader for this by including a small piece of code in the flash image to copy info from flash and the running app into RAM then reset, enter Bootloader and read the RAM image - typically using code like this in the Flash app:-

@mirror flash code into ram that is visible from bootloader afterwards as diagnostic
movs r3,#0x00; movs r4,#0x80; movs r0,#0x08000000; ldr r1,=mir_base; 
mirror: ldr r2,[r0]; str r2,[r1]; adds r0,r0,#4; adds r1,r1,#4; adds r3,r3,#1; cmp r3,r4; blo mirror

but its a very coarse debugger again as a fallback if all else fails.

Fourth item, documentation agreed. I can work out the commands (and have a small VS2022 C++ app to work with the bootloader) but the documentation is spread across AN2606 and AN3155 at least, attempts to cover all devices each with its own Bootloader activation pattern. I sympathise with ST on this.

Last item as regards in house experience, sticking to what you know works well. During development I would leave a piece of code (high in flash) that’s entered either by a special command or a pair of GPIO. once entered it allows standard methods for reprogram flash sectors etc.

Please let me know if I can help with anything.

Richard