Bug writing to FLASH with the CLI

[DWalk.3]

I've noticed what seems to be a bug when writing to flash with the '-w32' flag using STM32_Programmer_CLI. My order of operations is:

1. I erase sector 0 of the flash
2. I read the first 8 words of Flash and verified that it's erased.
3. I write some words to flash with the command:

   stm32_programmer_cli -c port=SWD mode=NORMAL reset=HWrst -q -w32 0x08000000 0x00000001 0x00000002 0x00000003 0x00000004 0x00000005

4. This write fails with the message:

   Error: Failed to download data! If it's a Flash memory, it may be not erased or protected

5. I read the first eight words of flash and it has this value:

   0x08000000 : 00000001 00000002 00000003 FFFFFFFF
   0x08000010 : FFFFFFFF FFFFFFFF 00000000 00000000
   
   

So it writes the first three words correctly, skips three words, then fills from 0x0800_000C - 0x0800EC7C with zeros. Certainly not what I expected/hoped!

I've attached a file showing all of the commands and the output. For reference, I'm using the STM32WLE5JC and version 2.15 of STM32CubeProgrammer.

Next, I'll try the -w64 command and see how that works.

[STOne-32]

Dear @DWalk.3 ,

Please let us know the status with 64-bits .

For this product STM32WL - https://www.st.com/resource/en/datasheet/stm32wle5c8.pdf#page96

 
Flash programming is only by 64-bits at a time. On other series it can be 32-bits . 

hope it helps you

Regards,

STOne-32

[DWalk.3]

64-bit works with the following caveat: the high and low 32-bit words seem to be swapped. For example, if I do:

> stm32_programmer_cli -c port=SWD mode=NORMAL reset=HWrst -q -w64 0x08000000 0x0807060504030201

When I look at the memory file, I see the following:

So the endianness seems to be "middle"; it consists of two consecutive little endian 32-bit words.

[DWalk.3]

I do realize that flash writes are done 64 bits at a time. I just thought the programmer would take care of this. If writes aren't supported, the tool should simply provide an error.

[Pavel A. · Accepted solution]

@STOne-32 and there are products that support 256-bit write units (STM32H7) which must be properly aligned. IMHO this should be elevated as stm32_programmer_cli bug and the feature reviewed. At least provide examples of correct use per STM32 family in the stm32_programmer_cli document until a proper fix is available.

@DWalk.3 

>I do realize that flash writes are done 64 bits at a time

IIRC it works this way (please anyone correct if this is wrong!)

* the 32-bit thumb CPU of course can only move 32 bits at a time, so actual writes are 32-bit.

* the flash module internally gathers N successful 32-bit writes into a "write unit" (specific to a model, for example 8 dwords = 32 bytes for STM32H7 or 2 dwords = 8 bytes for smth. else) .

* Once a write unit is filled up, the write actually begins.

* Some models have write units of 4 bytes or less

* If the CPU fails to fill a write unit in correct order - usually the error is detected and reported in status register, the gathered data can write partially or not at all.

[STOne-32]

Dear @Pavel A.  @DWalk.3 ,

I agree with your comments, it is complex that any tool will manage all use cases conditions not implemented in silicon and workaround the behavior  alike  across a very wide range of our STM32 MCUs having different Technologies of non volatile flash memories from 180nm to 40nm and complex topologies of Erase/Prog Co-Processor inside the NVM ( non volatile memory ) connected to the MCU buses . But we should highlight At documentation level to refer to product datasheet for supported options or once detected to have a warning message .  Thank you for the feedback, much appreciated- This is a real voice of the customer .

Cheers,

STOne-32