David, Thanks for the feedback. Our current design will directly link function calls between the AIDC and AIIC. It would not be safe to upgrade the application without upgrading the AIIC as well.
If we had to consider supporting upgrade of the AIDC without upgrading the AIIC, that would be a significantly more complex design. Paul On 6/21/16, 1:12 PM, "David G. Simmons" <[email protected]> wrote: >+1 This is very similar to how we handled upgrading images on a previous >IoT platform and it was very good at keeping customers from bricking >their device. I also like that it allows for the upgrading of just the >ADIC without touching a valid and functioning BLE Stack, etc. which makes >it more robust in that there is a lower chance of intruducing a >lower-level bug into the system simply by updating the application. > >dg > >> On Jun 21, 2016, at 3:31 PM, [email protected] wrote: >> >> I’m working on split image feature and I think I just have one more >>major design issue to consider, and that is newt build related. >> >> First, a summary for folks who are unaware of this effort. The goal is >>to create an application in two pieces to fit into two image banks such >>that one piece would contain the bluetooth stack and firmware update >>application and the other would contain the primary customer application >>(that’s the goal, but it would be defined generally to allow any split). >> These two are linked together with a special property that the upgrade >>app could run without the primary customer app but not vice versa. To >>give these names I call the independent one the AIIC (Application >>independent image component) and the customer app the ADIC (Application >>Dependent Image component). This would allow the following upgrade >>procedure with two flash images. At each step, there would always be a >>valid upgrade image loaded into the unit. >> >> 1. Erase the application image from the second image bank (still can >>recover since the upgrade image is valid) >> 2. Upload a new upgrade image to the second image bank (primary >>upgrade image still intact in case secondary fails) >> 3. Swap the upgrade images in the 1st and 2nd bank (if secondary >>doesn’t boot, we can always revert) >> 4. Load the new application into the 2nd bank (if this fails, we >>still have the upgraded in the primary) >> 5. Complete > >-- >David G. Simmons >(919) 534-5099 >Web • Blog • Linkedin • Twitter • GitHub >/** Message digitally signed for security and authenticity. >* If you cannot read the PGP.sig attachment, please go to > * http://www.gnupg.com/ Secure your email!!! > * Public key available at keyserver.pgp.com >**/ >♺ This email uses 100% recycled electrons. Don't blow it by printing! > >There are only 2 hard things in computer science: Cache invalidation, >naming things, and off-by-one errors. > >
