We have a design with two STM32H753XIH6.
One is the primary MCU, the other secondary. They communicate over SPI.
The built in SPI bootloader is used such that the primary MCU programs the secondary MCU.
When we checkout a freshly built unit, the primary MCU is loaded with its firmware via STLink/SWD.
Shortly after it starts running, it sees that the secondary MCU is not programmed, and programs it via the aforementioned SPI bootloader (mass erase command is sent, then the binary is written). Things have been running fine this way for more than a year.
We have a new batch of units with a new batch of STM32's. The above procedure no longer works.
What I have found is that the STM32 reports it has memory/flash protection enabled, and thus can't be erased.
These are untouched STM32's, and when connecting to them with STM32CubeProgrammer, the option bytes appear normal/factory fresh. There is no memory protection enabled. It is not possible to perform a mass erase on the chip.
As a workaround, I set the RDP to level 1, then back to level 0. This erases the chip, and it is now programmable via STM32CubeProgrammer. If the firmware (the same firmware the primary MCU would program to it) is programmed, it runs just fine.
The problem is, at this point, it is still not programmable via the built in bootloader. Upon sending the mass erase command, it responds with NACK, as if protection is active. I cannot figure out any way around this.
It is not possible to just program the secondary MCU via STMCubeProgrammer instead, as we use the SPI bootloader to update the secondary MCU firmware if there is a bug fix, feature change, etc. on devices in the field.
Attached is an image of a "good" and "bad" chip, for completeness.
