Bricking

This page describes how a CPU (likely your EFR32x22 radio board) can enter an unrecoverable state and how to avoid getting into this situation. Because your device will no longer be able to do anything after this has happened, it has basically become a small silicon brick, hence the term "bricking" your device.

alberhill_single_red_flashed.png

How Bricking Happens

Bricking occurs when a debugger is no longer able to access the flash memory of the MCU to alter it, and therefore the code that is on there will be stuck there forever. This might be OK, however the reason that the debugger can't alter it is usually because the MCU has run into a fatal situation where NOTHING works, such as accessing a state where it is waiting for a clock pulse, but there is no clock pulse coming to rescue it.

The most common methods of making a device unrecoverable are the following:

  1. Switching to a function that relies on a non-functioning or un-initiated clock.
  2. Going into a low-power mode.
  3. Issuing a reset.
  4. Disabling the debug pins.

If something like this is done really early on in the code, the debugger might not be able to sneak in before the MCU reaches a non-clocked state. The Silicon Labs 32-bit MCU family (like the Wireless Gecko that this project is using) has a start-up sequence with a 47-us window (between everything being locked and the program starting) of time that it could access the flash, but this might not be long enough (sometimes it is, depending on where the code hangs).

pastedImage_0.png
Image from [1].

Helpful Preventative Measures

  • The most helpful thing you can do for yourself is to add a nice big delay right at the beginning of your code, which will give your flasher enough time to wipe your CPU and start over.
#include "ustimer.h"
void app_init(void)
{
      ; // all your clock enable functions first, just in case
       USTIMER_Init();
       USTIMER_DelayIntSafe(1000000); // THIS 1 SEC DELAY WILL PROTECT YOU FROM YOURSELF
       ; // your other init functions after
}
  • Likewise, you can also add a delay before you are working on risky code, such as low-energy modes (especially EM3 and EM4) and messing around with clocks/oscillators.
  • You can also create a trap for your code near the beginning/risky part [2, 3] that checks if a GPIO / set of GPIOs is being held low. This will let you restart the device with the GPIO held in one position (for instance, with your board pushbutton held down) and will give you ample time to force an erase with your flasher.
while (GPIO == 0);

Device-Specific Checklist

These items are specific to the EFR32xG22 series, using SSv5.

  • Make sure you have initialized all of your clocks and oscillators. Ex: CMU_ClockEnable(cmuClock_GPIO, true); can be put right at the top of your app_init() function.
  • If you are using an evaluation board (such as the BRD4001), make sure the physical switch is set to AEM mode at all times, and that you do not accidentally move this switch when you are in the middle of working on it.
aem_mode.jpg
  • Make sure you are not assigning pins on the evaluation board that are crucial for some other built-in function. Ex: on the BRD4183 (32-pin QFN package), there is a low-frequency oscillating crystal (LFXTAL) on pins D0 and D1, so trying to use these pins for another purpose 1. won't work, and 2. could mess up your software if you are trying to use the low-frequency oscillator (LFXO).
brd4183_dpins.PNG
Image from schematic for BRD4183, sent to me by the manufacturer.

Signs Your Device is Bricked

If you are unable to write to your device, unable to unlock debugging, or getting the error message "DP write failed", your device has probably entered an unrecoverable state.

dp_write_failed.png

Attempting to Recover a Device

This is a non-exhaustive list of steps to try when you can no longer connect to and flash your device.

  1. Restart the device.
  2. Restart SSv5.
  3. Restart the computer (and then do both of those things again).
  4. Update your firmware [4]. (You can also do this through a terminal window, but this will not give you an advantage over using the GUI).
    1. Plug in your device.
    2. Open the Commander app, which can be found by navigating from Tools —> Simplicity Commander.
    3. commander.PNG
    4. Click "Connect" next to Adapter in the top-left corner.
    5. Navigate to "Kit" and browse for the right package in "Update Kit: Installation Package". For example, I am using 1v4p6b1171 with no problems.
    6. firmware_page.png
    7. Install package. You can repeat this firmware procedure as many times as you want to.
  5. Go into the Commander app and attempt to recover the device [5]. (You can also do this through a terminal window, but this will not give you an advantage over using the GUI).
    1. Plug in your device.
    2. Open the Commander app (see above).
    3. Click "Connect" next to Adapter in the top-left corner.
    4. Navigate to Flash —> Debug Lock Tools —> Recover bricked device. Click this and wait.
    5. commander_recover.PNG
    6. You can also try to unlock debug access, but it is using the same mechanism as "Recover bricked device".
  6. If these steps do not work, you will need to purchase a new radio board.

Things that will not help (I have tried):

  1. Installing an earlier version of SS (for example, SSv4).
  2. Trying to switch out of debugging mode (do not do this.)
  3. Trying to connect using other modes than AEM (do not do this.)

See Also

Bibliography
3. Silicon Labs Community Forum; 2019; EFR32MG21 bricked when uploading an application; https://www.silabs.com/community/software/simplicity-studio/forum.topic.html/efr32mg21_brickedwhenuploadinganapplication-qMxh
4. Silicon Labs Community Forum; 2016; Failed to unlock bricked BRD4001A; https://www.silabs.com/community/wireless/bluetooth/forum.topic.html/failed_to_unlockbri-cToV
5. Silicon Labs Community Forum; 2020; Debug interface doesn't work under USB power (EFR32MG21 radio board + wireless starter kit) https://www.silabs.com/community/wireless/bluetooth/forum.topic.html/debug_interface_doesntworkunderusbpowerefr3-iznv
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License