CubeProgrammer couldn't program board, CubeIDE could - STM32G0C1

[DDub]

Hello,

A custom control board using an STM32G0C1 stopped working after some time.  Upon plugging into the board and stepping through the program using the CubeProgramer, it was discovered that the PC was cycling through the same addresses repeatedly and getting hung up.  These memory addresses were traced back to various HAL delay functions using addr2line.  Normal operation involves the board initializing and executing various state machines in a superloop (no RTOS), not getting stuck in a "boot loop" delay.  

The entire flash memory was dumped to a .bin file and then an attempt was made to erase the flash using the CubeProgrammer with no luck and an error thrown.  No fuse bits or any kind of erasure protection was enabled during the programming of this board.  

Then the CubeIDE was used to compile some code and start a debug session.  Somehow, the CubeIDE had no issue loading a program into flash.  This is where it gets interesting.  After programming with the CubeIDE, another attempt was made to erase the flash using the CubeProgrammer and it worked!  What's even more interesting is the original full-memory-dump .bin file was programmed back onto the control using the CubeProgrammer, and everything now works fine.  No more "boot loop" behavior.  

It's almost like the program counter somehow got messed up and stuck in a wait loop.  But (1) How is CubeProgrammer unable to erase a board but CubeIDE can and somehow "fix" the flash and load a program and (2) How can "boot loop" behavior be observed at one point in time, and then after erasing flash and reloading the memory dumped program (should be exactly the same as what was originally in the flash), the control exhibits normal expected behavior?  

Any help or insight would be most kindly appreciated.  

DDub

[mfgkw]

Maybe different settings used?

Perhaps you have to "connect under reset", but did not set this with CubeProgrammer?

[TDK]

The intermittent behavior is likely the symptom, not the cause. Don't read too much into it.

The root cause sounds like an issue in the hardware. Maybe clock doesn't start under some scenarios, or there is an intermittent connection, or insufficient power, or other hardware design issue.

Debugging the board may show where it's stuck. Implement some logging capability out to a UART as it starts up and use that to diagnose.

[DDub]

Thank you for the replies.  This is a board that was returned from out in the field, so it's not possible to "turn on" logging capability, though I agree that it is very helpful for development.  After the board was reprogrammed with the exact same file that was originally pulled from flash, it behaved normal.  I can understand brown out resets, but then I would expect this board to behave normal on a bench setup with a solid power supply, especially after a power cycle.  This is a relatively mature design in both hardware and firmware with many successful use cases.  I'm just curious if anyone has ever seen this before or has any idea what else could cause the behavior described above.  

@TDK, what would be some example scenarios that would cause the clock not to start if it normally starts just fine?  As mentioned previously, this is not a "rev 0" board; its been in use for awhile and proven to be rather stable.  I'm just curious as to what could cause the intermittent behavior and how I could reproduce it, understand it, then eliminate it.  

Thanks!

[DDub]

Thanks for the reply.  

Maybe, but I was able to read the flash off of the chip, so I know it was connected to it.  I was also actively comparing the memory with an .elf file and that was successful, so I'm confident that the CubeProgrammer was connected.