Mass erase failing - STM32H533RET6

[lectricidiot]

Hello,

I have a custom STM32H533RET6 board that I can't program.  Following advice found on the ST website I am trying to use CubeProgrammer to mass erase the flash, however it is failing to do so.

I am using an STLINK-V3MINIE with Mode: Under reset and Reset Mode: Hardware reset

NOTE: the guide says to use software reset, but upon connecting CubeProgrammer switches this to hardware reset. I don't understand why?

I can connect to the the board and the mcu type is correctly identified

Here is the initial connection log:

11:47:25 : STM32CubeProgrammer API v2.21.0 | Windows-64Bits
11:47:40:870 : UR connection mode is defined with the HWrst reset mode
11:47:40:878 : ST-LINK SN : 003A003C3234510936303532
11:47:40:879 : ST-LINK FW : V3J16M8
11:47:40:879 : Board : STLINK-V3MINIE
11:47:40:879 : Voltage : 2.39V
11:47:40:879 : Connection to AP 0 requested and failed, Connection established with AP 1
11:47:40:880 : SWD freq : 8000 KHz
11:47:40:880 : Connect mode: Under Reset
11:47:40:880 : Reset mode : Hardware reset
11:47:40:881 : Device ID : 0x478
11:47:40:881 : Revision ID : --
11:47:40:881 : Clear all interrupts
11:47:40:881 : Reading data...
11:47:40:882 : r ap 1 @0x40022070 0x00000004 bytes Data 0xC300015C

Here is a sample of the log from when mass erase is initiated:

11:47:52:875 : MASS ERASE ...
11:47:52:882 : r ap 1 @0x40022040 0x00000004 bytes Data 0x01FF0001
11:47:52:882 : Flash erase...
11:47:52:883 : r ap 1 @0x40022070 0x00000004 bytes Data 0xC300015C
11:47:52:883 : halt ap 1
11:47:52:883 : r ap 1 @0x40022000 0x00000004 bytes Data 0x00000013
11:47:52:884 : w ap 1 @0x40022000 0x00000004 bytes Data 0x00000014
11:47:52:884 : r ap 1 @0x40030400 0x00000004 bytes Data 0x00000004
11:47:52:884 : w ap 1 @0x40030400 0x00000004 bytes Data 0x00000006
11:47:52:885 : r ap 1 @0x40022028 0x00000004 bytes Data 0x00000001
11:47:52:885 : w ap 1 @0x40022004 0x00000004 bytes Data 0x45670123
11:47:52:886 : w ap 1 @0x40022004 0x00000004 bytes Data 0xCDEF89AB
11:47:52:886 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000000
11:47:52:886 : w ap 1 @0x40022030 0x00000004 bytes Data 0x00FF0000
11:47:52:887 : r ap 1 @0x40022030 0x00000004 bytes Data 0x00000000
11:47:52:887 : w ap 1 @0x40022030 0x00000004 bytes Data 0x00FF0000
11:47:52:888 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000000
11:47:52:888 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000000
11:47:52:888 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000000
11:47:52:888 : r ap 1 @0x40022028 0x00000004 bytes Data 0x00000000
11:47:52:895 : w ap 1 @0x40022028 0x00000004 bytes Data 0x00008000
11:47:52:895 : r ap 1 @0x40022028 0x00000004 bytes Data 0x00008000
11:47:52:895 : w ap 1 @0x40022028 0x00000004 bytes Data 0x00008020
11:47:52:895 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000001
11:47:52:895 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000001
11:47:52:896 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000001
11:47:52:896 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000001
11:47:52:896 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000001
11:47:52:896 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000001
11:47:52:896 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000001
11:47:52:897 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000001
11:47:52:897 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000001
11:47:52:897 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000001
11:47:52:897 : r ap 1 @0x40022020 0x00000004 bytes Data 0xFF000001
11:47:52:897 : fail @0xFEEEFEEE
11:47:52:898 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000016
11:47:52:898 : fail @0xFEEEFEEE
11:47:52:898 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000016
11:47:52:898 : fail @0xFEEEFEEE
11:47:52:898 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000018
11:47:52:899 : fail @0xFEEEFEEE
11:47:52:899 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000018
11:47:52:899 : fail @0xFEEEFEEE
11:47:52:900 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000018
11:47:52:900 : fail @0xFEEEFEEE
11:47:52:900 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000018
11:47:52:900 : fail @0xFEEEFEEE
11:47:52:901 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000018
11:47:52:901 : fail @0xFEEEFEEE
11:47:52:901 : r ap 1 @0x40022020 0x00000004 bytes Data 0x00000018
11:47:52:901 : fail @0xFEEEFEEE

Full log has been attached.

Any ideas of where I'm going wrong?

[TDK]

> 11:47:40:879 : Voltage : 2.39V

Is that intentionally low?

[lectricidiot]

I've just checked with a DMM and the LDO is outputting 3.8V, which is also on the mcu VDD pins.  I'm not sure why it is low on the STLINK reading!

[TDK]

Well there's (one of) your problem(s). 3.8 V is above the operation conditions for the chip. Typically, the operating voltage is 3.3 V max.

The STLINK-V3MINIE is likely reporting the voltage correctly, so you should reconcile that as well.

Showing schematic may help.

[lectricidiot]

Thanks, I'll ask the engineer who designed the board for feedback on what might be going on.