OTA Update + Broadcaster / Observerer Functionality

[Anonymous]

I'm interested in learning if the following project functionality/configuration can be achieved with PSoC Creator:

   

A) A bootloader which supports OTA Update functionality using Cypress's bootloader / bootloadable approach as detailed in AN97060, preferably with a fixed stack, as the device I want to use (CYBLE-012011) doesn't have 256kB, so the upgradeable stack could only be achieved by using a more expensive device or with external memory, both of which I'd prefer to avoid.

   

B) The application would be using both Broadcaster and Observerer roles. The Broadcaster would be dynamically updating the manufacturer specific data in the advertisement packet, and the Observer would be looking for a special message to indicate it should switch into the bootloader for a firmware update.

   

Essentially I'm looking to create a beacon which also supports OTA firmware update, so any if any of the gurus out there could #1 confirm that this is achievable and #2 give me any pointers as to the best way to approach configuring a project / CyBLE block(s) to get this setup, that would be very much appreciated.

   

Thanks so much for your time.

   

Cheers,

   

-Jonathan

[rola_264706]

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. 

[Anonymous · Accepted solution]

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:

   

    
1. 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.
    
2. 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:     
         
   1. Client connects and enables GATT indications on the characteristic
         
   2. Server (beacon) generates a pseudo-random 16-byte sequence and pushes it to the client via indications
         
   3. Client must perform pre-arranged special permutation and write back the expected value to the server
         
   4. If correct value is written, server reboots into bootloader
         
   5. 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.

[Anonymous]

Thanks so much for your detailed explanation - very much appreciated! This has been extremely helpful in getting me started off in the right direction.