You should already have completed:
With all the necessary information and a determination of which processors need updating and which methods we can use, we can proceed to updating firmware. In general, we want to physically separate and individually update elements when we can. However, if we cannot easily disconnect modules from our system, always update from the furthest downstream module and work up from there. First starting with the furthest downstream Mote, then the Spotter Bridge, then finally the Spotter Main Processor.
<aside> ⚠️ At this stage, you should already have collected key information from all processors in your system and determined which need updating. If you haven’t done that yet, go back to the parent page.
</aside>
First, update all Bristlemouth modules. Ideally by removing them and updating them individually, or via bootstrapping if they are inaccessible. When bootstrapping, always start with the furthest downstream module.
<aside> ⚠️ As of May 30, 2024, all encapsulated Bristlemouth modules provided by Sofar Ocean are shipped on the latest v0.11 release, and do not need updating. If you have a Bristlemouth Sensor that you believe needs a firmware update, please reach out on the Bristlemouth community forum for assistance.
</aside>
Sync the latest Github release of the open source bm_protocol repository into your development branch and re-compile your application. You can follow the steps in Submodules for updating your git submodules and conda environment for building applications on the new version.
Or, download off-the-shelf Dev Kit binaries (such as Hello World) from the latest Bristlemouth application release:
If you have access to your target’s USB port, it is simplest and fastest to update the Dev Kit’s firmware using SWD or DFU with a direct connection*.*
Bristlemouth Bootstrapping refers to the process of updating all modules in a Bristlemouth system across an incompatible version change using only the Bristlemouth protocol, and doing so without needing to disassemble the system.
<aside> ⚠️ If you are deploying new custom firmware and do not have access to your target Mote’s USB port (eg if it is encapsulated into a module, or built into an inaccessible system) we strongly recommend that you test the updated version of the application on a bench-top development system prior to deploying. That way, if something goes sideways with your new firmware version you’ll be able to recover using DFU or SWD and debug the issue before deploying to an inaccessible Mote in your system.
</aside>
When you’re ready to deploy, you can follow this guide for how to bootstrap update using Bristlemouth across incompatible protocol versions:
Bootstrapping Bristlemouth Modules Guide