 Hello, I'm Alec Bath, Applications Manager for ST's wireless microcontroller products in the Americas. Today, I'm going to discuss Fuoda on the STM32WL. Fuoda? What's that? Funky unicorns on the airplane? No. It's a firmware update over the air. Today's connected world nearly every industrial, medical, automotive, computer, or consumer gadget around me has a microcontroller in it, and whether wired or wireless, firmware updates to improve the customer experience, patch security holes, and of course correct firmware bugs are pretty much mandatory these days. With wired connections like USB or Ethernet, the CAN bus in your car, or wireless links like Wi-Fi or Bluetooth low energy, this isn't too much of an issue. With a very long time on air of Laura WAN packets and the duty cycle and dwell time limitations on the unlicensed sub gigahertz spectrum imposed by the various regulatory bodies, this becomes challenging in the Laura WAN space. With bought rates on par with 70s era acoustic modems, it can also be a very time consuming endeavor. However, it's something that the Laura Alliance needed to address, as many of these end nodes are in very remote locations, and it's not so cost effective to send a technician out to the field to perform updates. So with a little help from our friends at Actility, our Nucleo WL55JC1 evaluation board, and some new features added to the Cube WL firmware library, I'll walk you through the process. The Laura Alliance has standardized on a client server protocol, that is an update client on the end node side, and a photo server on the network side. This protocol has three main building blocks for over the air firmware updates via Laura WAN, synchronizing the clock of an end node or the many end node clocks in a large scale multicast deployment to the network server's highly accurate GPS based clock. Next, standardization of the fragmentation and reassembly of the many dated blocks transported over the network. And finally, the standardized usage of Laura WAN Class C mode and multicast capabilities to save network bandwidth. As mentioned in the previous slide, photo uses Laura WAN Class C mode. Let's do a quick review of the three standard operating modes of Laura end nodes. Initially, having joined the network, all end devices must support Class A mode, of which all communications initiate on the end device side. Once done transmitting, two receive windows are opened for any downlink communications. For small battery powered end nodes, Class A mode is crucial. Class B adds more frequent receive slots via a periodic network beacon transmission for synchronization with some trade-offs for power and complexity. Class C is a nearly continuous receive mode, drawing the most power, but also quite useful for firmware updates down from the network, and so Fuoda, on a temporary basis, will use the Class C mode. Here we see the software layers of our SDM32 WL-based end device on the left, communicating to the network server via its gateways, the remote multicast server, and application server on the right. We can see the client-server relationship between the end device and RMC server, each with similar function blocks for firmware management, multicast setup, fragmentation management, and clock synchronization. As we know, LoraWAN has many layers of security, join keys, network keys, and application keys. Our network and application session keys can be derived directly using activation by personalization, or by the more common and secure method over-the-air activation, which uses our DVUI, AppEUI, and AppKey to derive our session keys. In addition to these unicast keys, Fuoda makes use of a new set of keys, multicast keys, which are common to all end nodes participating in the Fuoda campaign. Now let's review those hardware and software bits we'll need to get started with our Fuoda campaign. The Nucleo WL-55JC1 evaluation board for 868 MHz and 915 MHz regions in Europe and the Americas. Regions using LoraWAN in the 4-500 MHz range will use the low-band WL-55JC2 board. STM32Cube IDE, or alternatively the IR or Kyl development environments will also work just fine. STM32Cube Programmer, which our batch file scripts will use to program our STM32WL in command line mode, the STM32CubeWL firmware library, and finally a terminal emulator, such as TerraTerm, can be useful for monitoring progress. Navigating to the project's Nucleo WL-55JC applications, LoraWAN Fuoda folder within our CubeWL firmware library, we'll find the six main subfolders we'll use in our Fuoda campaign. Image BFU handles the integrity of firmware update versions and boots the device with it if authenticated. Image KMS Blob generates a blob binary file related to key management services. This is not directly used in our LoraWAN Fuoda campaign, however. ImageSecCoreBin generates our secure engine core binary file. LinkerCommon defines our WL's custom memory mapping for all of these software packages. LoraWAN Endnode is our traditional Endnode project, which you can use and modify as you wish with the addition of the synchronization, multicast setup, and fragmentation data block transport in the LoraWAN stack. Our scripts folder contains batch files unique to the three supported compilers mentioned earlier, STM32Q IDE, IAR Embedded Workbench, or Kyle Microvision. Here's a look at our STM32WL-55's memory mapping related to Fuoda. The first 88K hold our BFU vector table, secure engine, our boot and firmware update services, key management service data, and a small swap space. The next 84K is reserved for our photo downloaded image. Our active firmware image resides in the remaining high memory flash space. Before we run our build and program batch files, you'll want to ensure that the setenv.bat file is using the proper toolchain paths for your version of Q-Programmer and your preferred compiler toolchain. You can right-click on the setenv.bat file, choose Edit, and have a look. Once your toolchain environment variables are set, go to the Scripts toolchain folder of your choice and run the build batch file. First the KMS blob's image is built, the secure engine core is built, image BFU is built, our end-node application is built, some post-build processes and leaking are done, and we are ready for programming. This step took about two and a half minutes on my somewhat dated Windows 10 machine. Now run the program.bat file, your device will be mass erased, the binary loaded, which takes about 20 to 30 seconds. De-power the board, re-power, open terra-term, and you should see your device come up and attempt to join the network. Congratulations! Your SDM32 WL55 end-node is now photo-ready. Allow Handed Over to our friends at Actility to walk you through the setup and deployment process of your photo campaign on the network site. For additional information on firmware update over the air, head over to st.com, search for AN-5554 or just search for FWOTA. This app node will give you some great further detail on the process. Also AN-5544 has some pretty useful information on SPSFU and KMS. That's Secure Boot and Secure Firmware Update and Key Management Services. Thanks for watching!