In certain upload scenarios with Simplicity Studio or Simplicity Commander, you may notice a warning message about "bootloader and application mismatch" or "no bootloader detected" during upload, and afterwards the device will appear unresponsive as though application firmware is not running.. This usually happens when there is a mismatch between the application firmware image chosen and the bootloader image chosen in the Application Upload dialog or if the target's main flash was empty and no bootloader was uploaded although the application firmware expected one in the memory map. This causes the boot vector of the chip (at first flash address) to be empty because the application reserves space for the bootloader at the beginning, and so no program execution happens at all.
You can avoid this problem by following these simple guidelines:
•If uploading a HEX file as the application firmware, you probably SHOULD NOT be selecting the option for Simplicity Studio to also upload bootloader firmware (or should not provide a bootloader to the command line along with the HEX file), since HEX files provided by Silicon Labs in a wireless SDK almost always contain the appropriate bootloader (or lack of a bootloader) for the firmware anyway. Note that most SiliconLabs-provided HEX files include phrases like “with-standalone-bootloader” or “with-serial-uart-btl” (as opposed to "use-with-serial-uart-btl") indicate that the bootloader firmware is already present in the HEX file and does not need to be uploaded separately.
•Whenever you have a choice between an S37 file or an EBL file for application firmware, choose the EBL file, as this contains metadata describing the intended bootloader that the application was designed for, so Studio/Commander can more readily detect a mismatch. EBL files are also a bit smaller in file size (on disk) than S37 files.