sorry if this ends up being the length of a short novel, but I've had this experience recently while trying to do a custom build using frozen modules, seemingly found a resolution given further below. in your case, for a clean build from tested, working firmware, I've found issues with flashing mboot to be generally responsible for the error.
First, to get your board back in a working state, download the latest stable release of the firmware for the SF2 as well as the mboot dfu from here:
https://micropython.org/download/pybd/
so I guess PYBD-SF2-20200902-v1.13.dfu and PYBD-SF2-20190529-mboot.dfu
If the usual steps to get the board into dfu mode no longer work (hold USR, press RST, wait for the white LED to flash and then let go) then my solution here probably won't help... I encountered a similar situation ~6 months ago where the board was no longer recognized as a "DFU capable USB device" but can't remember exactly how I rectified it, possibly full board reset (
If you can get into dfu mode, do so, download each of the two files listed above and run the following from the folder where the files are stored:
sudo dfu-util -a 0 -d 0483:df11 -D PYBD-SF2-20190529-mboot.dfu
sudo dfu-util -a 0 -d 0483:df11 -D PYBD-SF2-20200902-v1.13.dfu
honestly haven't the foggiest how the '0483:df11' comes into play but I found the command in the 'README.md' in "micropython/ports/stm32"
Trick is to flash the mboot first as it dictates the way in which your board's flash should be partitioned.
Incidentally, and as a total aside to your question for anyone interested, I ran into this most often when trying to build custom firmware. For instance, I'm using a PYBD_SF6 on a 2011 macbook pro running OSX High Sierra (I know, I know); I installed gcc-arm-none-eabi through the brew package installer, but this installed the latest version which doesn't work correctly on my frankly ancient hardware.
so I downloaded the last release which works on OSX High Sierra (gcc-arm-none-eabi-8-2018-q4-major) to a folder in my user account, call the path "/Users/me/STM32Toolchain/gcc-arm-none-eabi-8-2018-q4-major".
I had this at the front of my path in my bash profile but was still encountering the frozen white light. Found that I need to pass the correct gcc-arm library to gmake specifically and that the mboot and firmware dfu's required different libraries to be built/interact correctly.
So while in the "micropython/ports/stm32" folder I run the following command to build the overall firmware:
sudo gmake BOARD=PYBD_SF6 LIBS="/Users/me/STM32Toolchain/gcc-arm-none-eabi-8-2018-q4-major/lib/gcc/arm-none-eabi/8.2.1/thumb/v7e-m+dp/hard/libgcc.a /Users/me/micropython/drivers/cyw43/libcyw43.a"
(for a PYBD_SF2 i believe the correct library would be "[etc...]/8.2.1/thumb/v7e-m/hard/libgcc./a")
then change directories to "micropython/ports/stm32/mboot" and run:
sudo gmake BOARD=PYBD_SF6 LIBS="/Users/me/STM32Toolchain/gcc-arm-none-eabi-8-2018-q4-major/lib/gcc/arm-none-eabi/8.2.1/thumb/v7e-m+dp/softfp/libgcc.a"
(again, switch that to "[etc]/8.2.1/thumb/v7e-m/softfp/libgcc.a" for an SF2)
connect the pyboard through USB, enter DFU mode, and while still in "micropython/ports/stm32/mboot", run:
sudo dfu-util -a 0 -d 0483:df11 -D build-PYBD_SF6/firmware.dfu
then from "micropython/ports/stm32" run the same command
sudo dfu-util -a 0 -d 0483:df11 -D build-PYBD_SF6/firmware.dfu
again replacing "build-PYBD_SF6" with whatever's relevant.
This took me ages to figure out and isn't necessarily an answer to your question, but I did think it might be helpful for anyone else who's gotten the white light of death trying to do a custom build.