STM32H750 flash corruption with double buffering enabled

[nattgris]

Hi,

It seems there is a problem with the flash write routines for STM32H750. A simple program like the below gives corrupted flash for about one out of five attempts for a 30 kB file, without any type of sign that something went wrong.

#!/usr/bin/env python3
from pyocd.core.helpers import ConnectHelper
from pyocd.flash.file_programmer import FileProgrammer

with ConnectHelper.session_with_chosen_probe(target_override='stm32h750vbtx') as session:
    FileProgrammer(session, chip_erase="sector", smart_flash=False).program("file.elf")

Looking at the diff, it appears that some pages are only partially written with only the first part containing correct data, and the rest of the page being 0xff.

I was very surprised to find that neither the FileProgrammer helper, nor any of the underlying classes, support built in verification of the flash contents after programming. This is a fundamental feature of any flash programming tool. Of course you can do a manual compare separately, but that command does not have the same file format support as FileProgrammer.

I added verification support to the FlashBuilder class for easier debug of this problem. I can send a PR after some cleanup and exposing through FileProgrammer if there is any interest.

After testing a lot of times with the verify support active, it seems corruption only happens with double buffering enabled, and regardless of whether using sector erase or chip erase (which is a lot slower on STM32H750 for some reason). I don't see any way to switch off double buffering except changing the builder code, since the builder method to disable it doesn't seem to be exposed all the way up to FileProgrammer.

[nattgris]

I would think #1696 has the same root cause, since the chips are from the same family and probably uses the same flash algo.

[nattgris]

I found a builtin target stm32h743xx which works much better than the Keil.STM32H7xx pack, after being modified for the H750 flash layout. I made 100 programmings in a row without any problems, whereas the CMSIS H750 pack flash loader failed after on average 2 programmings.

By the way, I think the H743 support added in #1567 lists the wrong sector size for the flash, which should be 128K, but is listed as 8K in the flash algo dict, and 32K in the memory map. I assume this must be a mistake.

Is this the correct issue tracker for CMSIS-PACK bugs? Otherwise I think this issue can be closed. I will send a PR adding the verify support and a new builtin target for H750.

[newbrain]

Just to add a data point:
I'm having the same symptoms, while trying to program the STM32H750 on a Daisyseed board.
The success rate is about one out of three tries.
It seems to be independent of the used probe, I've tried a CMSIS-DAP LPClink2, a Picoprobe, and a JLink mini EDU.

Programming and verifying work flawlessly with the same probes when using OpenOCD.