Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
Is there any technical limitations that would prevent the OTA update to happen between two BCM20737 modules? I don't see an issue as long as the BLE application is small enough to shelter a copy of the firmware used for the OTA in RAM and the OTA protocol is implemented properly in the module (GATT etc...).
I may have a BCM20737 module in the field that receives over PUART a firmware that would be used to do an OTA update of sensors (peripheral BCM20737 modules). The central would behave in the same manner as the smartphone application that initiate OTA update.
I have a similar task. I am using BCM20736 modules. I would program module A (first BCM20736 module) with firmware via the uart. I would then like to have it (module A) replicate its firmware OTA to a second Module B (also a BCM20736). Module A would only update a second device when instructed. Is there any limitation in "replicating" firmware OTA between BCM20736 modules? All of this would initially not be using the secure process.