Hi Eddie,
Here are some notes which hopefully will help.
This refers to CC2340R5, silicon revision B (PG 2.0), using the RTM SDK 7.10.00.35 which was released last week and the current capability contained in this release.
The SDK has BLE examples for on-chip OAD and off-chip OAD.
In both cases, the bootloader is 'mcuboot' which takes ownership for starting up the device. This is programmed at program location 0x0 in internal flash, and also contains the CCFG device configuration data (clock config/etc). The mcuboot image is configured at build time to specify where the OAD image 'slots' are to be found. When mcuboot starts up, it checks each of the 'slots' and then executes the appropriate image. Each slot contains metadata about the image, which includes version details, key information, checksum and signatures, etc. If both images are valid (checksum/signature/etc), mcuboot will boot the image that has the highest version number. If both version numbers are the same, then the primary slot will be used.
There are 2 prebuilt 'hexfiles' for the on-chip and off-chip mcuboot contained in the examples/hexfiles folder.
For 'on-chip' OAD, mcuboot is configured to have 2 internal 'slots' in on-chip flash. One of these slots is usually configured as a bigger area to store the main 'application' image. The other is used to store a smaller 'persistent' image. The 'application' image (basic_ble_oad_onchip), holds the main application firmware and a minimal 'OAD Reset Service', which is used to signal to the system to reboot into the 'persistent' image (basic_persistent) whenever an OAD update is triggered. This is done by the OAD Reset Service invalidating the application image (setting it's own version number to 0), such that mcuboot then selects the persistent image on the subsequent boot. The 'persistent' image contains the full OAD Update Service and is used to transfer a new application image into the application slot.
The default on-chip OAD memory map used in the sdk examples is laid out as follows :
[On-Chip Flash] 0x00000000 - 0x00006000 : [0x00006000 ( 24k)] mcuboot 0x00006000 - 0x00032000 : [0x0002c000 (176k)] basic_persistent [ secondary slot ] 0x00032000 - 0x0007c000 : [0x0004a000 (296k)] basic_ble_oad_onchip [ primary slot ] 0x0007c000 - 0x00004000 : [0x00004000 ( 16k)] NVS Storage Data
The full OAD service contained in the persistent image, transfers the new application binary into the application slot and then reboots. Mcuboot then checks the application image, and uses it if is valid.
For 'off-chip' OAD, mcuboot is configured to have 2 'slots'. One of these slots is contained in on-chip flash and the other is contained in off-chip serial flash. The internal slot (primary) is the one that contains the current image (and this is where it is executed from). The external slot (secondary) is used to contain the new update image. Mcuboot will check the image in the external slot and if it is valid and newer it will copy the image into the on-chip flash primary slot and then trigger a reboot to use the new image. In the case of off-chip OAD, the application image contains the full OAD Update Service.
The default off-chip memory map used in the sdk examples is laid out as follows :
[On-Chip Flash] 0x00000000 - 0x00006000 : [0x00006000 ( 24k)] mcuboot 0x00006000 - 0x0007c000 : [0x00076000 (472k)] basic_ble_oad_offchip [ primary slot ] 0x0007c000 - 0x00004000 : [0x00004000 ( 16k)] NVS Storage Data [Off-Chip Serial Flash] 0x00000000 - 0x00076000 : [0x00076000 (472k)] basic_ble_oad_offchip [ secondary slot ]
To create the images for the mcuboot 'slots', there is a post-build-step added, which calls the mcuboot 'imgtool'. The tool adds the 0x100 byte header (which includes information such as the version, image size, etc), and the trailer (which includes the key/hash/signature). The image can also be padded (--pad) to fill the slot size. The padding also adds some copy flags and status bits which are needed for Off-Chip OAD images. This means that Off-Chip OAD Images are required to be padded to the overall slot size (0x76000 in the examples). On-Chip images do not need to be padded.
The BTool application, contained in the SDK, and the latest iOS / Android applications can be used to test and demonstrate these capabilities. These apps are here :-
Connect mobile application -
The binaries for the OAD Update and info on flashing the base image is currently contained here
I hope that helps a little,
~roger
