You don't start out chosing a particular frequency. That eventually falls out of other requirements. Just the frequency spec accross a broad range of processors is pretty meaningless.
The real spec is some minimum performance or latency reqirement the processor has to meet. In general for any one microcontroller, processor performance is proportional to clock speed. A large portion of the power current is also proportional to clock speed, so that is one reason to not make it wildly higher than needed in power-sensitive applications. For high end general computing processors, performance is not necessarily proportional to clock speed because there are issues like cache hit percentage, memory latency, etc. Small microcontrollers intended for self-contained embedded applications don't usually have these kinds of advanced architectures and performance is pretty much linear with clock speed.
However, clock speed is a poor indicator of performance accross different microcontroller architectures. Some microcontrollers, like low end PICs for example, require 4 clock cycles per instruction cycle, some 2, and some even just 1. Then there are differences in what each architecture can accomplish in a instruction cycle. Comparing clock frequency between anything other than related processors in the same family is largely meaningless.
Another issue is that some micros have fancy internal clock chains including PLLs and dividers. The purpose is so that they can run at a variety of speeds from easy to use and find crystals. 8-16 MHz is a nice frequency for a crystal. You can certainly use crystals well outside that range, but 8 MHz is about the limit where really small packages become available, and having the external clock be otherwise as slow as reasonable is a good thing. That then brings up the question as to what the "clock speed" really is. Is is the external clock frequency you actually feed into the chip, or what the chip derives from that inside before using it otherwise? Each of these are relevant in different ways.
In short, focusing on microcontroller "clock speed", whatever that really means, is like obscessing about piston displacement and turbo boost overpressure when all you really want to know is horsepower and fuel economy. You have little reason to care how they got there, only what the result is.
Yeah, it's entirely possible. I commented on this previously and have since looked into it further. You can have the triggering Bluetooth device send the activation signal through its friendly name.
The friendly name is the human-readable name that appears in the the list when you search for a Bluetooth device to pair with. The speed at which this activates depends on how quickly the receiving device polls for friendly names. You haven't mentioned what type of receiving device you're using but I found this PDF (Pg.35) detailing the process for updating the friendly names of in-range Bluetooth devices.
You can poll for friendly names as often as you require. If your triggering device changes its friendly name to the activation code, abc123
, then the receiving device will be able to see that name without pairing and activate whatever task you're attempting to perform. This also allows you to have a multitude of activation codes, I think you can get up to 248 bytes for the friendly Bluetooth name.
You may also look into intentionally opening yourself up to Bluejacking. I'm not familiar with it, but if security isn't an issue it could work.
Best Answer
Yes, you can do remote firmware updates with the STM32.
Now you have two choices:
Using the factory-programmed bootloader requires booting the chip with pin BOOT1 pulled low and BOOT0 pulled high, and the Bluetooth module needs to be connected to a specific USART peripheral (there are other interfaces, depending on the specific STM32 model, but I assume the USART makes the most sense here). Also, you need to write an app to interface with the bootloader, following the bootloader's command protocol which is documented here. To avoid writing code to interface to the bootloader, you could use the STM32 Flash Loader demonstrator application; of course this requires that the other end of the Bluetooth connection be plugged into a PC, so it doesn't make sense in every scenario.
The other possibility is writing your own bootloader, which gives you more control. You can, for instance, trigger the bootloader using a software-only sequence, so that you don't need to set certain pins as required by the factory-programmed bootloader. Of course, writing such a bootloader involves a lot more effort than using one that is already written, tested and shipped with the MCU.
Some brief comments about writing your own bootloader. A bootloader is a piece of firmware code like any other. It's loaded into the MCU during the production (or debugging) process together with the main code.
Despite being code like any other, since the bootloader is used to reprogram the MCU's firmware, it merits a few special considerations. First of all, for simplicity, you may want to make your bootloader a fully separate piece of code from your main code. Edit the bootloader's and the main code's linker scripts, so that each uses a completely distinct segment of flash memory. That way, you can update the main code without touching the bootloader. When the bootloader is part of the main code, if the updating process encounters any kind of problem, then your device is bricked. Bootloader code needs to be very reliable, since a bug in a bootloader may be the difference between the user being able to service the device by himself after a botched update, versus being forced to take it to a service center. Personally, I'd make the bootloader as small and simple as possible, even going so far as to avoid using interrupts, since in a way they make code less predictable. Usually I'm all for interrupts, but this is the one case where I'm against using them.
Briefly, a bootloader is loaded when the device boots, and usually just hands control over to the main code. However, when performing a firmware update, then the bootloader runs its own code after boot instead. This code must include some kind of communication (in your case) or storage driver, so it can receive/read the binary for the updated code, via Bluetooth, Ethernet, an SD card, flash drive or whatever. It then erases the old code and reprograms the flash memory with the new code.
One of the tricks that must be done when reprogramming the flash memory is relocating (copying) part of the bootloader code to the RAM, since you can't run code from flash while it is programmed (even if the address being read is different from the address being programmed). Also, the updated binary code that is going to be written to flash must be in RAM as well. Usually there won't be enough RAM to store the full code for the update, so it's not unusual to receive/read a partial block of code, write it, receive/read another partial block of code, write it, and so on.
Programming flash memory is not a simple matter of writing data to the desired addresses. There's a flash programming manual for each member of the STM32 series (for instance, here is the manual for the STM32F10x series). In brief, due to low-level details of how flash memory is implemented, before reprogramming a given block, you'll need to issue an erase command to it. Also, you can't make any reads from flash while it is being programmed, so forget about interrupts, DMA, etc. unless there's just no chance that they'll try to read from flash while it is being written.