Error: Mass erase operation failed. Please verify flash protection

[MAlan.1]

Currently running into an issue with a custom PCB with a STM32H750 MCU on it. We use an SWD connection to connect to the debugging port. When I go to fully erase the external memory, I receive an error message that is "Error: Mass erase operation failed. Please verify flash protection". If I try and program the device using my binary file, it says the core is locked up. The other 9 boards program fine. Is this a hardware issue more than likely or am I missing something?

[Tesla DeLorean]

The voltage reporting suggests you don't have VTarget wired up.

Is the board properly powered? The QSPI Flash is apt to fail if not powered adequately. The charge pumps is going to be working quite hard during write and erase to get the higher voltages internally to change the state of the array.

If the External Loader returns errors from Init(), Write(), SectorErase(), etc these will be reflected to you via the user interface. Want more details, instrument your loader, output diagnostics and flow dynamics via an available UART.

QSPI Flash memories can fail to Write() or MassErase/SectorErase() if the array is write protected. Perhaps look at the BPx bits in Status Register1 (you don't mention a specific part/model), or sector level protection if you've enabled that, accidentally or not. Most parts don't report an "Error", but rather the commands complete immediately without performing the requested operation. Micron's has FLAG STATUS registers providing slightly more information.

These BPx bits can get set by using the wrong manufactures methods to enable 4-pin operation, there's a Macronix sequence that locks Micron parts, for instance. The sense of the bits can be inverted on Winbond parts via the COM bit.

[MAlan.1]

Board is powered. We got this firmware from an outside party. It has worked on 15 of the 16 PCBs we have. This one is having issues though.

[Tesla DeLorean]

You have any methods to test or query this "QSPI Memory Device" from within your own code, or resources?

The Memory device might not be viable. Issues with soldering or internally. The Block Protection methods in the memory device can be sticky, they are designed to prevent write access to the array. If they are set accidently or not, the result will be the same. Code something that clears them.

I don't have magic abilities to see inside as to what specifically is happening.

If you've got no method to query the device in-situ, then remove the memory device, and try another. Save it so you can perhaps review via another board/socket arrangement which you do have dominion over.

Suggest you read out the JEDEC ID, and STATUS REGISTERS [1..3], per device data sheet.

So 1 out of 16, could still be component level failure, debug as you would normally.