Erase/Program/Verify worked fine before, now fails on erase with almost no changes

[NTuzz.953]

Hello all,

We are developing a product with a STM32L071x8 uC in it and we're using STM32CubeProgrammer to upload firmwares to it. We used to be able to upload firmwares with no issues. However, ever since we developed our newest firmware, we have been having issues with using Cube. Usually- but not always!- the erase that takes place before the programming process will fail. If we skip the erase and just go straight to the program and verify, the firmware goes in fine, and the product passes our test suite.

We have replicated this issue on multiple PCs, with multiple STLINK-V3s, on multiple targets, and as stated, the firmware seems to be working fine as once it's in the device it passes all of our testing. Does anyone have any suggestions for why the erase operation might be failing when our process includes one firmware but not another? Thank you in advance.

[Tesla DeLorean]

Is NRST wired on the debug interface?

Any code changing settings/configuration for PA13/PA14?

Low power modes, via WFI, disabling pin banks?

[NTuzz.953]

NRST is wired. It's pulled up on the board, and we are not currently connecting to it with the programmer.

As far as I know the changes to the firmware were minimal, but even if they were not- why would that make it fail during erase...? The program operation without an erase works fine.

[Tesla DeLorean]

NRST really needs to be wired to gain control of the IC during initial connection. The debugger wrestles control as the processor executes, so code early in the reset path can cause interference with that task. The CM0(+) also having a purely SWD based connection, and lacking full JTAG support.

For the V3 I would definitely back off the clock to 1 or 4 MHz, I don't think 24 MHz is sustainable.

>>..but even if they were not- why would that make it fail during erase...? 

I don't work for ST, their software in recent years has been very flaky and poorly tested, especially in "non ideal" conditions. I can't tell you why it doesn't function in any given situation, only suggest strategies that will improve the chance of success.

[NTuzz.953]

I forgot to mention- we're using the bootloader I2C interface to do this programming.