Unlock Bootloader Bricked Phone

[Agenor Ramadan]

Iwas attempting a STM32 firmware update over the I2C interface using some other host MCU. For this, I used the NUCLEO-G071RB; so I referred to the ST's AN4221 and implemented their firmware update flow.

I configured the option bytes using STM32CubeProgrammer so that the STM32 bootloader can be accessed using the BOOT0 pin instead. I had already implemented their UART firmware update flow and I had got it working without any issues. But now our product needs to perform the firmware over I2C instead. So I made the necessary changes so that the host MCU uses the I2C interface instead of UART to communicate with the STM32 bootloader.

As mentioned in their AN2606, I used 0x51 as the slave address for STM32G071RB bootloader. Also instead of using their old UART commands, I switched to their I2C No-Stretch commands (so as to avoid clock stretching while communicating via I2C). I was able to successfully communicate with the STM32 bootloader. I sent the "Get ID" (0x02) command to the bootloader and I received an ACK and was also to fetch the Chip ID (0x460).

Once I was able to fetch the Chip ID, I sent the "No-Stretch Readout Unprotect" (0x93) command and I received the ACK byte (0x79) for that command. Now I waited for the 2nd ACK (which would be received once the STM32 disables the readout protection and performs mass erase on the entire flash memory).

So I kept polling until I was receiving the BUSY byte (0x76) and waited for the ACK (0x79). But I never received the ACK, the MCU kept receiving the BUSY byte atleast for 40 seconds while in the STM32G071RB datasheet the mass erase time is mentioned to be just 40.1 ms.

Since the program execution was stuck for quite a long time, I reset the whole system. Then I tried the whole thing yet again, but this time the bootloader completely stopped responding to the I2C commands. It stopped giving an ACK (the 9th bit) on the slave address itself. I suspected something was wrong with the MCU since it was working fine before.

So I tried communicating with STM32G071RB using STM32CubeProgrammer (over ST-LINK) but it started throwing this Error: No STM32 target found. I then checked the FAIL.TXT file, it said "The interface firmware FAILED to reset/halt the target MCU". I suspected that the STM32's user application might be corrupted and that might be blocking the ST-LINK SWD pins so I configured the STM32CubeProgrammer (changed the Mode from Normal to Under Reset) so that it can initiate the communication with the STM32 MCU just after it has come out of reset but that didn't work either. It returned the same Error: No STM32 target found. I tried the same thing by manually resetting the MCU as well as forcing the MCU into the system memory (bootloader) whenever it comes out of reset (by tieing the BOOT0 pin high) but even that didn't work. I also tried using the UART interface but none of the things worked.

I found this under the Flash option byte programming section (in STM32G0x1 reference manual). Could it be that I might've corrupted the option bytes, since I was trying to write the RDP bits in the option bytes (by issuing the Readout Unprotect command through the bootloader).

It says that it erases the user option bytes and rewrites it in the next cycle by fetching the previous values from the option registers along with the option change that the user requested. So is it possible that I might've bricked the device by resetting the MCU while it was performing the mass erase and also changing the RDP option (although I waited for atleast 40s before doing so) or is the MCU damaged because of some other reasons? Also if such a scenario can permanently brick the device, then how should we handle this case in production where one can't be sure about power outage during the firmware update?

While any OBL_Lauch or POR is performed, option bytes are not loading. Moreover the reset has to be properly perform to avoid any glitch on reset line and corrupt option bytes register. Any corruption induces a mismatch which actually enable the BOOT_LOCK and RDP level 1. Then, the device is permanently lock. There is no way back.

Since you asked, I didn't write any application code to program the option bytes so I didn't have to follow any programming sequence. I tried programming the option bytes via the STM32's proprietary boot loader instead. I sent the Readout Unprotect command to the STM32 boot loader to disable the Readout protection as mentioned in the application note AN4221.

Any update on this? Just to clear it up again; I tried programming the option bytes through the STM32's boot loader and not through my own application. Is it possible for them to get corrupted this way and end up with the device getting bricked?

For a few minutes, after loading blinky_led and trying to move to the next example, I was stuck with the controller mounting and showing up as bootloader. It would periodically reboot and remount every minute or so. So I tried updating the firmware by dragging-and-dropping the .bin file from FRDM-K66F Mbed . Now the board doesn't even light up when plugged into USB and Windows doesn't recognize any device being plugged in. If I plug into the power port, blinky_led will run.

I have a second board but I'm afraid to use it. I plugged it in hoping that I could use it to install the Windows ARM serial driver, as I was receiving "no microcontroller found" with the bricked one - nope still get error despite this being the very first instruction on the aforementioned mbed website. So I tried to do this right, and held down reset to go into bootloader mode, and at the beginning of a remounting cycle, tried to copy over the firmware. NOPE! firmware is 95kB and I only have 92kB of freespace on the board! Also, the article says DAPLink needs to be upgraded if it mounts as "bootloader" - ok, but of course, there is no FRDM-K66F listed in the table: DAPLink bootloader update Mbed . I would use the K64F, but its such a fragile piece of equipment, that I'm afraid to.

None of the instructions to keep this delicate thing from dying seem to work. My second board is now stuck in bootloader mode, probably soon to be bricked as well. Please help. I want to use this board, but I'm frustrated by how out-of-the-box instructions don't work and can actually kill the board. I haven't even tried anything unique yet.

Got board #2 working ok. For some reason I showed 98kB of free space when loaded into Linux and could copy the firmware, which made the device appear as a drive called FRDM-K66FD. And then the serial driver would install correctly. I'm still stuck short of having a probe to allow debugging. I checked my downloads, I believe I dropped blinkyled.bin onto the BootLoader drive which killed the first board - I did not drop firmware. Hopefully there is a repair for this mistake.

I'm trying to put the bin files inside of the bootloader, however, as soon as I drag and drop the file I get this error, I've attached a screenshot.

When I try to drag and drop the 0224_k20dx_bl_0x8000.bin file the board gets ejected automatically.

The GrapheneOS installation guide strongly recommends relocking the bootloader after flashing for security reasons. For example, I read somewhere that full disk encryption may be vulnerable when the bootloader is left unlocked. Before I lock the bootloader, I wanna understand the implications of this. If I understand correctly, I can unlock the bootloader again at any time as long as I'm prepared to lose any data on the phone and the custom ROM signals that OEM unlocking is enabled.

Wireless3811 Suppose the flashed OS is unable to boot, and OEM unlocking is reporting as disabled. Would my phone be hard bricked in this situation or is there anything I'd be able to do to save the phone?

Nothing is perfect, so there is no way to guarantee that a working phone won't be permanently bricked. But it is genuinely very rare, especially if the web installer is used. If there is a hardware failure, e.g., a critical part of the flash memory goes bad, that can be disastrous, but an unlocked bootloader is not likely to help.

But what if a future update goes wrong? On LineageOS this has happened to me before: device works fine, I update, softbricked due to bootloop. I believe this was during an Android 9 to 10 update or something, it has definitely been a while.

Wireless3811 Pixels and GrapheneOS uses A/B updates. Meaning that if you're currently running on A, the next update is installed on B and will automatically roll back to A if it can't boot properly. And then it does the opposite next update.

Please keep in mind that a lot of people get into one or another kind of trouble with GrapheneOS by not adhering to the project's advice. People disable system apps, remove permissions from system apps, enable various developer options, etc., and get into weird situations that are difficult to debug and may require a device wipe. As with leaving the bootloader unlocked, in the end what to do will be up to you. But the project's advice is carefully considered.

To be clear here, locking the bootloader isn't really an optional thing. If you don't lock the bootloader, you don't have a successful GrapheneOS installation, and in many significant ways, you're not really running GrapheneOS.

Thanks for your input everyone. I've locked the bootloader. I'm a still a bit on the fence about OEM unlocking. If I understand you correctly, it's unlikely that I'd softbrick my phone due to an OEM lock because I need a successfully booting ROM to disable the OEM unlock and due to the A/B update mechanism that automatically rolls back updates that don't boot.

On my RUT955 (HW Rev 1106, FW 00.06.06_WEBUI, factory defaults) the bootloader update to 3.2.5 bricked the device. The only lifesign of the router is a blinking LAN3 LED. Many other users seem to have the same problem. Teltonika has removed the bootloader download in the meantime.

These are strong signs that the devices were damaged by a faulty bootloader software. Shit happens but please act responsible and offer a solution to get the broken devices back to work. I love these devices and have about 20 of them.

3a8082e126