One issue with using a device that doesn't have enough resources is that you have to add external devices. You could use a I2C memory and write your data to it.
It is possible to create a beacon with OTA support, although you might want to take a slightly different approach. Rather than trying to use both broadcaster and observer roles simultaneously (which would actually require selecting the Profile configuration with Peripheral and Central GAP role to have access to all necessary APIs), it would be easier to use the following configuration:
- Profile configuration
- Custom profile with one writable custom GATT characteristic defined in the Profiles tab
- Server profile role (no client needed)
- Peripheral GAP role (no central needed)
Rather than using the Observer role and scanning for special packets to trigger a Bootloader reset, you would simply allow connections and use the GATT characteristic as the trigger mechanism. There are a few advantages to this method:
- Scanning typically uses a lot more power than advertising, even advertising in a connectable state. The reason for this is that scanning requires a very high active RX duty cycle to work reliably (often 50% or more). Connectable advertising, on the other hand, is usually closer to 1% RX duty cycle depending on the advertisement interval.
- Using GATT transfers for the trigger gives you more straightforward control over what actually constitutes the trigger signal. You could require a special value to be written (known passphrase), or something more complicated like a challenge-response mechanism. For example:
- Client connects and enables GATT indications on the characteristic
- Server (beacon) generates a pseudo-random 16-byte sequence and pushes it to the client via indications
- Client must perform pre-arranged special permutation and write back the expected value to the server
- If correct value is written, server reboots into bootloader
- If incorrect value is written or client takes too long (e.g. 5 seconds), server disconnects client and disables connections for 1 minute (a sort of anti-brute-force safeguard)
The design complexity will be less with this approach than with the combined broadcaster+observer configuration, and the power consumption should be much better.
You could start from the Fixed Stack example project (which is a BLE peripheral) and go from there. The fixed stack and upgradeable app should fit on a 128k part.
Thanks so much for your detailed explanation - very much appreciated! This has been extremely helpful in getting me started off in the right direction.