Hello, my name is David Lara. I'm part of the CMCU Embedded Processing business unit. And I would like to welcome to the BLE over-the-air download with LZ4 compression and security session.

This session will cover in details the most common topics that a customer will experience while integrating Bluetooth Low Energy over-the-air download into their existing products. What you will learn today is MSP432 security features, LZ4 concepts and how to use the libraries, boot loader concepts and architecture, the SimpleLink SDK, the SimpleLink Bluetooth plugin.

Well, this is a detail agenda that we will cover today. We're going to start with reviewing the typical end equipments that you can find in your home. After that, we're going to go into the platform overview of the SimpleLink devices. Then, we're going to cover the MSP432 in a more detailed way.

After that, we're going to dig into the Bluetooth Low Energy over-the-air download example. And then, we're going to cover the LZ4 libraries. And finally, we're going to give you a benchmark on the data that we collected using the LZD4 libraries and the over-the-air download example.

So we are trying to solve the problem of downloading speed and code portability. This solution was developed as an extension of the over-the-air download example that is part of the SDK Bluetooth Low Energy plugin. And we are targeting any of the BLE applications, or Bluetooth Low Energy applications, that required in-field firmware upgrades.

And the key components of this particular systems are the MSP432 that access the MCU host and the CC2640 that acts as the Bluetooth low energy radio.

So what we are going to discuss today could be applied to most of the things or end equipments that are connected, or will be connected, in your house. A good example of these end equipments are motion sensor, door control, lighting control, window control, security alarm, and temperature monitoring, just to mention a few.

So again, what is the problem that we are trying to solve? Well, most of these end equipments will require over-the-air firmware upgrades. And in some cases, the time that it will take you to upgrade these end equipments, it will be-- or it will not be acceptable. So that's what we're trying to solve.

In some cases, using LZ4 encryption libraries will reduce the speed of downloading the new image into these particular end equipments. Another thing that we're trying to solve is code portability. In a typical development scenario, a customer might initially develop a stand alone ultra-low-power thermostat.

As their business grows and customer demands changes, the customers sees the need for a Wi-Fi enabled thermostat to allow the end of users delivers to Wi-Fi connectivity for home automation.

Down the road, the customer also sees a need of a Bluetooth Low Energy thermostat for phone pairing. And they develop another thermostat. And now, the customer is also moving to a gateway sensor network in an industrial setting. The functionality of the thermostat is not changing. So the goal of this customer is to reuse the same software that was developed for the standalone thermostat, correct?

Designing new products and applications is not as easy as it might seem. Developing new products from the ground can require a large investment in tools, software, and time to learn the new design environment. So code portability is something that the customer will have to look into.

So that brings us to the SimpleLink MCU platform.

So the SimpleLink MCU platform brings together industry leading connectivity solutions with TI proven arm based microcontrollers. Customers need more than our word. The SimpleLink microcontroller platform offers a single development environment with 100% code reuse. A one-time investment in the SimpleLink software development kit allows customer to reuse often, opening the door to create unlimited applications. It's really easy.

Again, developing connected application is challenging, time consuming, and expensive. So we need a unified software solution with hardware and resources that will decrease our customer development investment and future. This is what the SimpleLink MCU platform is.

The SimpleLink MCU portfolio includes a comprehensive development tool environment with free software, tools, and low cost development kits. All of this is combined with a single software foundation that enables unprecedented scalability with 100%--

code reuse across the SimpleLink SDKs. Customers are no longer limited to one MCU or one connectivity standard customers have flexibility of hardware, software and tools through a powerful intuitive and comprehensive development ecosystem. With industry and standard API STI drivers and TI artos, TI provides a robust foundation for application development. All these resources are available today.

So let's go back to the example before. The SimpleLink SDK maximize developer's return on investment. The SDK allows designers to develop an application on one SimpleLink MCU, such as the MSP432, and then reuse the application on a different SimpleLink MCU, like the CC3220 wireless MCU, to add new functionality without starting from scratch.

This also applies to the Bluetooth Low Energy and the sub1 gigahertz products. So at the end, you will be able to reuse your code in all your products.

Now let's dig a bit more into the SimpleLink MSP432 device. But before that, let me give you another example.

Well, this slide shows an example of a typical security system. The e-lock or access panel is a good example of equipment that were required in-field upgrade.

Let's assume for a second that a customer is complaining that a 256 kilobits image was taking close to 5 minutes to program in this particular end equipment. So let's assume that for the next generation-- next generation of product, they add more features. And their e-lock code grows to close to one megabyte.

This will give us a ballpark of close to 20 minutes to upload a new image into this new e-lock. Honestly, I don't think that you want to be locked outside of your house for 20 minutes while you need to upgrade your e-lock. So what will be the best way to improve this?

OK, so let's take a deeper look into this particular equipment. First of all, we need a host microcontroller. In our case, we select selected the MSP432.

At the same time, we're going to need a radio, a Bluetooth Low Energy radio. And we selected the CC2640.

Also, there's going to be a keypad on the system. And we could use the CapTIvate FR2633 that will enable the CapTIvate technology. At the same time, we're going to need a device that will allow you to download the new image into the radio and into the MSP432.

And everything comes together using the MSP432 SDK and the Bluetooth Low Energy plugin.

So far, we discussed the problems that we're trying to solve. At same time, I gave you a couple of good end equipment examples where we see a need for having this particular problem solved. Now, before jumping into the solution, I would like to give you an overview of the MSP432 SDK Bluetooth plugin.

OK, so let's start with the SDK concept-- SDK plugin concept. Plugins are intended to extend functionality of each individual base SDK to include specialized use cases. These specialized use cases can range anywhere from adding wireless functionality to extending a base SDK example base.

It's important to know that each plugin contains all the necessary component to function fully along the base SDK.

In regards to the MSP432 SDK Bluetooth plugin--

This particular plugin is made as a complimentary software package that adds full BLE capabilities to your SimpleLink MSP432 SDK projects. So let me give you a little bit of history about the SNP and SAP. The SNP stands for Simple Network Processor. And the SAP stands for Simple Application Processor. In this particular image, the Simple Application Processor is MSP432. And the Simple Network Processor is the CC2650.

The communication layer between the MSP432 and the CC2650 has been instructed away using the Simple Application Processor Driver. The Simple Application Driver allows for a generic and portable interface between the MSP432 and the CC2650.

Additional training can be found in SimpleLink Academy. The MSP432 SDK Bluetooth plugin contains a good number of examples that will get you started with your Bluetooth Low Energy application. These code examples, for example, the Project Zero, is a starting point for the BLE development and includes several capabilities, such as LED control, button monitoring, and basic data storage.

The Simple Application Processor is a simple BLE example which showcases several capabilities, such as notification and basic Bluetooth properties reads and writes. We also have a Sensor BoosterPack that showcases the BoosterPack-- the Sensor BoosterPack to provide broadcast of a variety of different sensor data over BLE.

Also, we have a Temperature Sensor Broadcast that leverages the MSP432 integrated temperature sensor to particularly broadcast temperature data. Also, the LCD Text BoosterPack code example gives you a user ability to draw texts with variable position colors on the Kentec QVGA BoosterPack.

And finally, the Over-the-Air Download demonstrates how to update the firmware of the MSP432 and CC2650 over the BLE without the need to store the whole firmware images on the MSP432. And it is worthy to mention that this particular example was used as a reference to develop the solution on the-- that we could be discussing next.

The Over-the-Air Download code example is a powerful code example that shows user how to update the firmware on the Simple Network Processor or in the Simple Application Processor over-the-air from a BLE client device. Now, let's talk about how the MSP432 memory was organized.

The memory is divided into different banks, bank zero and bank one. When the firmware images are downloaded on the device, there are stored at-- in the over-the-air image storage area. As you can see, in this particular example, it's above the to 20,000 address.

And it's at 128 kilobytes of size. Also, something that it's worthy to mention is that it comes-- this particular example comes with an over-the-air download boot loader. And that's what we're going to be discussing next.

In regards to the boot loader, the boot loader was developed in a way to support multiple communication protocols. One of the task of the boot loader is to verify that the application is valid. And if the application is valid, it will give the control to the application.

Now, when the application has-- or has stored a new image in the flash, that application will be decontrolled back to the boot loader. And then the boot loader will run the-- its reprogramming state machine in order to upload the new image on the application.

So the boot loader is located at the beginning of the flash. In this case, it goes from zero to 1FFF. That gives us eight kilobytes of memory. Then after that, we-- it's reserving some memory for the application code.

The application code size-- or the memory allocated for the application is on only one to 116k. This is a 256k device, so the remaining of the memory that its 132 kilobytes is reserved for the over-the-air download images.

This is the flow that the boot loader will run when-- after reset. And pretty much what it's going to do, as I mentioned before, it's going to check if the application is valid. And if the application is valid, it will give the control to the application.

Also, the application will send a signal to the boot loader when it's time for it to take control and then upgrade the new image that was received and was already stored in the reserve memory.

OK, let's go back to the problem. Using the over-the-air download example that is part of the SimpleLink Bluetooth plugin, downloading an image size of 128k, it takes about two minutes. So for a 512 kilobytes, the time that it will take you to download this size of memory-- it should take us close to maybe eight minutes.

And also, if-- let's say that we have a 1 meg image. The timing will go up to close to 16 minutes. So how can we solve this problem? A good way, or one way, to solve this particular problem is using compression. So let's talk about LC4 and what it is.

So let me give you an introduction of LC4. The LC4 compression utility is a lightweight compression library optimized for ultra-low-power MSP432 microcontrollers. The software is based on an open source LC4 specification, an algorithm. And it's compatible with existing LC4 software and files.

This makes LC4 an excellent choice for an ultra-low-power embedded device, where compression and decompression are equally important to target applications. The LC4 algorithm provides a perfect balance of compression performance and functionality for a wide range of embedded applications, Such as data logging, expanded data storage, over-the-air data transfers, and more.

For more information and the full specification, you can go to the LC4.org.

So this graph shows four different images that were compressed using the LC4.

As you can see, there's a good improvement in most of the images. And specifically, on the Simple Network Processor that it goes-- it went down to 27%. The over-the-air download firmware image, it only went down to 2%. We also run the compression on the MSP432 BLE lock application.

And that one, we saw a reduction of 32%. And then finally, we just put both images together and just to understand what was going to be the compression ratio. And in total, we will got a 25% reduction or compression.

OK. So let's run the LC4 plus the over-the-air demo. First, we used the LC4 tools to create the new-- the new firmware.

Then, we upload the image into a mobile device.

Then we download the image into an MSP432. We use the MSP432 to demonstrate the code portability, multi-image support, and also, in the near future, multi-protocol support.

We use exactly the same memory allocation for the compressed image. But the uncompressed image is being stored in RAM. We have to 256k of RAM in the MSP432. So we wanted to use the RAM for this particular device. And then finally, we programmed this to 62650 using the BSL.

Now, let's take a look at the results. The full image took us 65 seconds to download. Now, the image with the LC4, it only took us 48 seconds. So this is a good way to reduce the time of the over-the-air download. This brings us to the end of the session. Thanks so much for listening. Goodbye.