Flashed STM32F405xx with Klipper.bin using ST-LINK utility, now can't connect at all - help!

[FPayn.1]

I am trying to 'kliperize' my FlashForge Creator Pro 2 (FFCP2) 3D printer which uses a STM32F405xx MCU.  I was able to connect to it using the ST-LINK utility and a ST-LINK module (see this link for my post on this subject). With the ST-LINK utility I was able to display and then capture the entire 1MB memory of the MCU for safe-keeping in case I ever wanted to restore the original firmware, but now I can no longer connect to the MCU either with ST-LINK utility or ST32MCubeProgrammer.  I have checked and double checked my USB cable and my ST-LINK connections, power-cycled and reset the FFCP2 printer, but nothing seems to work.

Have I managed to 'brick' my FFCP2 printer?

TIA,

Frank

[Tesla DeLorean]

The boot-leg ST-LINK might be problematic

Ideally want connection of 3V3, GND, SWDIO, SWCLK, NRST

You need the RESET for "Connect Under Reset" to work

Not clear from the pictures exactly what's wired up, and what errors it is reporting.

[FPayn.1]

Yeah, I thought those photos would be sufficiently clear for documentation, but maybe not so much.  After careful examination, I have the following connections.

           MCU SWD    ST-LINK

GRN      GND             GND

YEL       DIO              SWDIO

ORG     CLK             SWCLK

With respect to NRST, I don't see that available on the MCU SWD connector.  With respect to 3.3V, I don't think that is required.  I didn't have it connected originally and the ST-LINK connection worked fine.

[FPayn.1]

(Duplicate - merged into original thread)

I have a FlashForge Creator Pro 2 3D printer that I want to 'Klipperize' (replace the current firmware with Klipper)  The motherboard uses a STM32F07ZGT6 with 1MB flash.  Before replacing the original FF firmware with Klipper, I first connected to the MCU using a ST-LINK/V2 clone and saved the entire 1MB flash memory contents to a file on my PC.

Unfortunately, after the Klipper flash I was unable to reconnect to the MCU via ST-LINK.  I was eventually able to regain connection by connecting BOOT0 to VDD while power-cycling the motherboard.  Then I re-loaded the flash memory with the binary file I had saved before starting.  After the load I can see where English language control labels are stored in flash, so I'm pretty sure the programming operation was successful.

Unfortunately, the printer will still not respond when I power it up; it acts like it isn't starting the program in firmware.  I have tried resetting the unit using the reset button, and I have even verified that the reset button pulls the NRST line to GND.

Any ideas would be appreciated.

TIA,

Frank

[Ozone]

I would say the easier solution is to put the old firmware back in.
Not sure where you got that update from, but obviously it causes problems.

The other option is debugging the new firmware.
I don't know much about this printer, so I can only give general hints.
First, look out for serial outputs on the motherboard (including unpopulated connectors),  which might be used for debug output. Perhaps you can catch some output.
Attach the ST-Link + debugger (either your toolchain, or a generic one like e.g. "Ozone" from Segger).
Try to attach to the "running" target - I would expect it to be stuck in a hardfault handler. Or try to reset, and single-stepping through it, to check where it ends up.

The source code is helpful, bu one can do without.

[Tesla DeLorean]

STM32F07ZGT6 ???

Dupe  https://community.st.com/t5/stm32-mcus-boards-and-hardware/flashed-stm32f405xx-with-klipper-bin-using-st-link-utility-now/td-p/735196

Perhaps the firmware is board locked via the STM32 Unique ID or keys/data in OTP ?

You should perhaps find a forum focused on this board, I don't think there's a lot of people here with specific understanding of issues with this board and it's firmware. Does the board manufacturer have a forum, or support channel of some form?

You'd probably need to debug the issue to understand what code does and does not execute. So use a debugger, and disassemble the firmware and understand what's actually happening here.