TI Crypto Bootloader Example Image

Hi Taylor,

SLAU657 (http://www.ti.com/lit/pdf/slau657 ) has a lot of this information, but I understand that it's not easy to know where to start and we appreciate your feedback. 

Taylor Hardin said:

rom what I can tell, IAR somehow loads CryptoBootloader_005856B5.txt (which is a hex representation of the compiled cryptobootloader code??) onto the msp430s FRAM, which gets called by Sample_App/main.c whenever P1.1 goes low. So, my question is, can you give me the actual C code for CrptoBootloader_005856B5.txt, or instruct me on how to place in memory using the command line mspgcc tools?

Section 6.1 of SLAU657 explains how to load crypto-bootloader for the first time using either the binaries or source code.

As discussed in the document, there are different tools that can be used to load the binaries, but one simple and free option is MSPFlasher.

The document also explains how to load the bootloader using IAR. The firmware is in "CryptoBootloader_1_00_00_01\firmware" but as you already saw, the software package only includes support for IAR. Unfortunately, GCC wasn't tested.

Taylor Hardin said:

Is it possible to combine the cryptobooloader C code with the main.c code and upload it all at once?

There are two different projects to avoid dependencies and to show that you can write your application "independently" of the bootloader. When creating an updated version of the application, you will only care about that binary and not about the bootloader.

Now, having said that, I understand the need to have both images on the same project, especially during development. While it is possible to do this, the current projects don't support this feature and they are independent. 

Taylor Hardin said:

Are there any measures/mechanisms in place that prevent the cryptobooloader from being overwritten by a new firmware image that's being uploaded?

If the new image is loaded using the bootloader (as explained in Section 6.2.3), then the bootloader itself will: 1) make sure that the image is valid through authenticated encryption, and 2) prevent access to protected areas (such as those used by the bootloader). The bootloader uses the MPU to prevent unauthorized access to memory as described in section 2.2.3.1.

During development, it is possible to download and debug the application using JTAG. Section 6.2.1 has some details about it.

Taylor Hardin said:

If I have a target device A and source device B, does the device B have to do any special formatting for sending the new firmware image to device A, or can it just send a hex image similar to CryptoBootloader_005856B5.txt and let the crypto boot loader on A handle the rest?

Device A doesn't need to do anything to the file except send it to device B using the commands found in Section 3.2.

Note that you will need to create a deployable image of Device B's application as explained in Section 6.2.2. But device A is just a "dumb" programmer and doesn't have to do any of the encryption/decryption/authentication.

Taylor Hardin said:

I'm working on a project that needs to support over the air firmware updates for an msp430 device.

Finally, I don't know if you are planning to get the new image using a wireless interface controlled by this MSP430 directly, or if you are planning to have a second device getting the data wirelessly and passing it to the MSP430 via I2C or UART.

But please note that the current CryptoBootloader image only supports I2C or UART as discussed in section 2.1, but it is possible to modify the peripheral interface as explained in section 7.1.1/7.1.2. 

Regards,

Luis R