STM32H753 Custom Board – "Unable to get Core ID" After Flash Erase in CubeProgrammer

[santhosh16]

Hey everyone,

I'm working on a custom board based on the STM32H753 MCU. I successfully programmed it using STM32CubeIDE initially, but ran into an issue when trying to re-flash it — I got the error:

"Unable to erase flash memory to reprogram it"

To work around this, I connected to the board using STM32CubeProgrammer and performed a full chip erase using the following settings (details below). I clicked Apply, and the flash erase appeared successful.

After erasing, I’m no longer able to connect to the board via either Cube IDE or Cube Programmer. I now get:

"Unable to get the core ID"

• Debug Interface: ST-Link  external

• Board was connecting and programming before the flash erase

• Now completely unresponsive via SWD.

• Does full flash erase wipe the area that contains the boot/configuration code, preventing debug access?

• What hardware signals should I verify?

• Is there a way to force the MCU into a recoverable mode
  I will also share the schematics

Note:

This is not exactly the same as my previous post where the MCU was never detected at sudden. In this case, it was working, but the issue started after a successful erase

[TDK]

Booting from flash memory means running the user code that's already on the chip. Obviously that's possible--that's what it's doing.

[santhosh16]

oh sorry, what i meant was its mentioned that we can still able to write to user flash memory. so by using that feature we can still able to program the board. we are looking for any methods related to do that, kindly mention.

[TDK]

I feel like you're missing what is being said here. If you have set RDP 2, the normal methods of flashing the chip are not available. The programmer cannot connect. Ever. There is no way to reverse this. There is no backup. There is no undo.

> its mentioned that we can still able to write to user flash memory.

User code can still read and write user flash memory as normal (HAL_FLASH_Program, etc.). However, unless your user code is already set up to do this, it will not help you here.

[santhosh16 · Accepted solution]

---

@TDK wrote:

If you set RDP 2, you can no longer access the chip with STM32CubeProgrammer. There is no way to recover the chip. It's done. Replace it with another chip.

---

ok fine as of now i set this as the solution since we have our development board in developing condition the protection is set to level 2. we're helpless to access the flash so for our case it might be the reason behind this.