Automate build process

[sudotensor]

Currently, to setup the two examples (MCUBoot and Mock) for demonstration, the build instructions in their associated documentation has to be followed step-by-step. This process can be quite cumbersome and isn't entirely ideal for testing.

Instead, this build process can be automated through a simple bash script that performs every step in the build instructions (listed under requirements) for the end-user. The program would take in as arguments the target board, example, and more (such as the mount point and toolchain). The demonstration step would be the only part that requires manual intervention.

Note: For now, the aim is to focus on supporting bash scripts as it is widely available and easily maintainable. In the future, there may be a possibility to migrate the functionality to a CLI program written in Python. Also note that steps for the Mock example are a subset of those required for the MCUboot one.

Requirements:

• Set up the environment
• Create the signing keys and build the bootloader
• Build and sign the primary application
• Create and flash the “factory firmware”
• Create the update binary

Associated branch: build-process-automation

[sudotensor]

There are slight kludges with how the MCUboot and Mock examples are built. The former is a direct result of dependency conflicts between mbed-tools, pyocd, and mbed-os. The latter is a result of issues with flashing the target binary to the connected board. The details of both are addressed below:

1. Dependency Conflicts: The difference in version requirements of the PyYAML dependency imposed by both mbed-os and pyocd led to the creation of a temporary virtual environment; this is used in the "creating and flashing the factory firmware" stage of the MCUboot example build process. This is a known issue and would require changes to the requirements.txt file in the mbed-os to resolve.
   
   Another minor conflict that doesn't hinder the build process is one between mbed-tools and mbed-os on the version requirement of the Click dependency; mbed-tools requires that the minimum version of Click to be greater than 7.1 while mbed-os requires it to be greater than 7.0. Now, the dependencies for mbed-os are installed after those of mbed-tools, which overwrites the newer version and generates a conflict. This would (again) require changes to the requirements file in the mbed-os repository to bump up the minimum version number of Click to 7.1.

2. Target Binary Flashing: For the Mock example, compiling with mbed-tools results in the following error:

   ERROR: Build program file (firmware) not found <path to mock example>/target/cmake_build/<target board>/develop/<toolchain>/target.hex
   

   The tool is looking for a hex file under the cmake build output whose name comes from project directory (in this case, "target"). However, the generated one is named BLE_GattServer_FOTAService.hex. Again, this is a known issue and has been filed (282) in the mbed-tools repository by noonfom.

Also, please refer to the important update in issue #3 for more information on why both the old mbed-cli and the newer mbed-tools are used simultaneously.

[sudotensor]

The base functionality of the script has been achieved, as indicated by the ticked requirement boxes. Though, the script as of 789a886 is quite long and inconsistent. The next phase involves a refactoring effort to make the cli tool easy to use and maintain. This would also involve adapting the script to work without a provided mount point - this is required for the CI workflow where the script is run without a connected board.

[sudotensor]

As of 67d89c5, development work related to this issue has been completed. The FOTA tool, its usage, and additional notes will be documented through #2 in the documentation branch. The CI workflow has been setup in #4 and will be merged into master soon.

Issue resolved ✅