Factory new STM32H7 says memory protected, can't erase flash via bootloader (previous batches work)

[inojosh]

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.

[Tesla DeLorean]

Perhaps you should contact the factory more directly with paper work and trace codes.

Talk to your sales rep or FAE.

Open an online support request  https://ols.st.com/s/

[inojosh]

I suppose that is the next step... I was hoping that maybe there was something I was missing that perhaps someone else has run into.

[AME MCU Support Center AD]

Hello @inojosh, thanks for reporting this. The team is currently looking into it (Internal OLS ticket #00196275). I will get back to you as soon as I hear back from them. 

[AME MCU Support Center AD]

Hello @inojosh, posting this in case it helps others with a similar issue in the future. 
As you figured out, changing the SPI frequency from 8MHz to 4MHz for SPI bootloader fixed the issue. 

[BarryWhit]

@AME MCU Support Center AD , but what was the root cause? is this a silicon erratum? signal integrity issues on the customer's board? a custom bootloader violating timing requirements ? 

Why would lowering SPI speed from 8Mhz to 4Mhz solve this kind of issue?

[AME MCU Support Center AD]

The customer suspects that the internal oscillator of this batch of MCUs was trimmed differently from the other batch. 

However, the MCU was not RMA'd and the die was not analyzed. An internal search revealed no other reports of a similar issue, and therefore it is also possible that the issue may not be related to the MCU. 

[Tesla DeLorean]

@BarryWhit OP seems to be talking about the built-in loader in "ROM" so AN2606 and AN4286

https://www.st.com/resource/en/application_note/an4286-spi-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf

As this is a "Slave" the clock would be coming from the external source, probably not synchronous with the STM32 side clocking, and dependent on the speed the system loader is running the MCU. The inputs on the STM32 are going to go through resynchronizers, so some Nyquist / aliasing considerations there.

H7 so HSI notionally 64 MHz, with some trimming values being preloaded, selecting HSI/PLL might disturb those.

[BarryWhit]

Should not depend on clock rate as long as the synchronizing side is sufficiently faster then the clock from master (synchronizers usually designed for 2-3 cycles to settle). If it really was 64Mhz synchronizing a 8Mhz signal, I would not expect this to be the issue. 

and if toggling the RDP cures the issue (thought that could be an example of n=1 case), then crystal drift should not be affected, therefore also not the cause.

Perhaps OP hasn't really figured out the issue so much as they made it "go away".