#157 Flashing STM32F103ZG - can only erase 154 pages, but not 155+

[Andrew Pullin]

I am running into an odd problem here, trying to flash an STM32F103ZG, one of the "XL-Density" 1MB parts.

I have been unable to flash my ~800KB main binary.
Erasure for pages 0-422 is reported, which sounds correct,
but the program just hangs when trying to erase the pages.

After some iteration, and creating various size random binaries via DD,
I have come to find that trying to flash a 308KB binary, 154 pages, will work.
But a 155 page 310KB binary will not work, and the program hangs.

Very odd. I've looked at the bootloader protocol docs and the stm32flash code ... everything seems to be in order.

Notably, I am running on OSX on Apple Silicon. Code builds with clang/make with no gripes at all.

Why am I not just using the STMicro flasher utility, some might ask?
Well, I am using Apple Silicon, and their flash utility always crashes on OSX on Apple Silicon!
(I think it is becasue it is still x86_64, and running an entire x86 JRE through emulation)

I am close to just starting a blank-page implementaion in python ...

[Andrew Pullin]

For the sake of thoroughness, I am creating the binaries via:
dd if=/dev/urandom of=test.bin bs=2048 count=154
and
dd if=/dev/urandom of=test.bin bs=2048 count=155

and flashing with:
./stm32flash -b 115200 -w test.bin /dev/cu.usbserial-A107L5XO

[Andrew Pullin]

Alright, I am going trout of my mind over this.

I finally went to the extent of installing a serial port sniffer in Windows,
and using the official STM32CubeProgrammer there to flash a longer binary,

and, sure enough, their extended erase command transmits 0x63 as N, to erase only 100 pages at a time.

Changing the stride from 511 to 99 in stm32_erase_memory and rebuilding makes flashing now work.

Great that that isn't documented anywhere at all, thanks STMicro.
jeeeeeeeeeeeeez

[Tormod Volden]

Thanks for digging through this issue. I share your frustration with ST.

I wonder if STM32CubeProgrammer uses 100 as a limit for all devices, or adjusts it depending on the detected device?

We could also reduce the limit to 100, but with a resulting performance loss for non-buggy devices.

[Andrew Pullin]

Not sure how to handle it, really. Having complete support would be great, so other's don't get stuck like I do.
But given the number of people who appear to have success with other STM32 parts and other versions of the bootloader, this might be one unique exception. Or there might even be low-RAM parts that have a lower limit.

I suppose I'll open a technical support ticket with ST Micro, and ask if they have a complete list of special-case rules like this ...

[Stefan Wagner]

Hi Andrew, I had the same issue with a STM32F103VG. This is also a XL-Density chip.

You can find my findings and (similar) solution in https://sourceforge.net/p/stm32flash/tickets/140/

@tormod Seems both tickets address the same problem