 Hello. Welcome to everyone to this webinar. This is Paolo Scarnizio, Technical Marketing Manager at ST. We see Vic Stefanec from the application team. We are very excited to talk about STM32WB as a wireless expansion of the STM32 family. 2.4 gigahertz, multi-core, protocol, powerful wireless MCU to support ZigBee, Bluetooth Low Energy, thread, and proprietary stack protocols. Today, we will focus on ZigBee and Bluetooth Low Energy. You can find a lot of additional information on ST.com slash STM32WB. So, let's start with the agenda for today. We start from a product and ecosystem offer. You will follow two live demonstrations showing ZigBee out of the box and ZigBee plus Bluetooth Low Energy concurrent mode. We'll touch the main takeaways from this presentation and finally, at the end of this webinar, our technical expert and me will be pleased to answer to your question. So, let's start. When it comes to connect objects within a short range, we can distinguish basically two approaches. Point-to-point or point-to-multiple communication with smartphones and other one-of-the-vices where Bluetooth Low Energy plays a strong role nowadays. And the more complex mesh network where we have high Tripoli 802.15.4 MAC-based stacks such as ZigBee and thread, or we can have Bluetooth Low Energy 5 Mesh or proprietary protocols as well. In many cases, the mesh network must be accessible from a smartphone like in the picture. The two approaches have different targets, complexities and advantages that are and product-dependent. Let's see how STM32WP can address both approaches and more. The STM32WXMCU brings one connectivity to the rich STM32MCU portfolio. The STM32WX series covers both gigahertz as well as 2.4 gigahertz frequency range operation. They are easy to use, reliable and perfectly tailored for a wide range of industrial and consumer applications. Let's focus today on the STM32WB 2.4 gigahertz wireless MCU. The STM32WB wireless MCU series features a two-in-one architecture built around a totally independent course. A CortexM4S application MCU based on the best-in-class ultra-low-power STM32L4 and a radio transceiver based on a CortexM0 Plus to manage high-level stack protocols such as 802.15.4 MAC-based ones and Bluetooth Low Energy. Only one deeply integrated and highly cost-efficient system on chip with announced security features. A STM32WB solution does a perfect match between real-time and highly power-efficient applications. The STM32WB platform is eager to seek for our fellow engineers looking for more than just a regular device where PCB size and cost care more than everything. Looking at the ST portfolio that offers ZigBee and Bluetooth Low Energy today, we have four devices available now. The SuperSet, the STM32WB55 and the STM32WB50 devices. STM32WB35 is a reduced cost version available today. A video line device is available as well today, STM32WB30. These have the lowest cost STMicro Bluetooth Low Energy plus 802.15.4 solution. Let's jump a bit into the STM32WB block diagram. The innovative architecture of the STM32WBM's use is based on two totally independent cores optimized for real-time execution. This enables flexible resource usage and power management for a lower BOM cost and a better user experience. 64 MHz Cortex-M4S is dedicated to the customer application, while at 32 MHz the Cortex-M0 Plus is fully dedicated to the radio protocol stack and time critical tasks. STM32WB MCU has been developed with the same technology as our ultra-power STM32L4 microcontrollers. It provides the same digital and analog peripherals suitable for applications requiring an extended battery life and complex functionalities. STM32WBX5 wireless MCU are available in multiple packages up to 7x7 BGA 129. And different memory sizes up to 1 MB flash 256K background. It includes a wide variety of communication features including a practical Crystallize USB 2.0 full speed interface, audio support, and LCD driver touch sensing up to 72 GPIOs, some of them 5-bolt tolerant, code SPI with execution plays, and an integrated switching mode power system, SMPS, for power consumption optimization, and multiple low-power modes to maximize battery life. An integrated balloon is available as well to further reduce complexity beyond cost and space on PCB. STM32WB55 can run protocols in concurrent mode as we will see later. The STM32WB55X operates on the range from minus 40 up to 105 Celsius. The STM32WBX0 value line focused instead on the essential and offers a feature-optimized cost-effective solution for developers. It enables entry-level solution features essential peripherals set with a reduced temperature range. A dual-core processing leads to a lot of benefits. Let's dig into some of them we at ST are considering as key differentiators. Independent radioactivity means the radio core works totally independently from the Cortex-M4F domain. These are those all routines and time critical are half-secret job to run on Cortex-M0 Plus. Energy setting mode is active when neither Cortex-M4F nor Cortex-M0 Plus have tasks to run. With 256k by RAM retention and RTC running, STM goes down to 2.1 microamps, still performing a 5-microsecond fast wake-up. On the other hand, the application core Cortex-M4F runs the main application activities independently from Cortex-M0 Plus. For example, for computing data sensors, let's see both Cortex-M4F CPU speed up to 64M allows to set up the right computational power. The dedicated interfaces such as batch acquisition mode, BAM, allows peripherals that transfer through DMA with CPU and flash turned off. And when both cores are running in parallel, the overall power consumption is as low as 50 microamp meters. Application MCU Cortex-M4F and radio MCU running in parallel communicate through an inter-process communication channel. Last, when the system has to shut down, for example, for battery setting, we can count on a power consumption of 50 nanoamps only. In addition to its wireless and ultra-low-power features, STM's AT2WD microcontrollers embed security features which reduce device maintenance needs and ensure that devices are trustable and cannot be cloned. Other security functions such as 256-bit AES hardware encryption, PC-ROP read-write protection, JTAB fuse, and public key cryptography with an elliptic curve encryption engine are available. The firmware upgrade services, SUS, the secure boost and secure firmware upgrade, SDS-SU, together with PC-ROP and PKEA feature ensure secure wireless stack update on the field, secure application firmware update, encryption key management and code protection. It works to a light that ST is fully committed on releasing new versions of the protocol stack fully back compatible with the previous version to minimize the development effort, if any. Wireless stack firmware are provided encrypted and signed by ST, while it is up to customers to double-sign the package when needed. Here is a summary of the entire portfolio of the STM32WD devices we have today and to be released in mass production by Qoom4 2020. As we have done with the STM32 devices, we have created a large portfolio with multiple flash, RAM and packages options. With these offerings, we have a device that is suitable for most customer applications. We have not touched on the STM32WD15 and WD10 devices represented on the bottom left pink box. These will be in production in Qoom2 2021 and offer the lowest cost dual core Bluetooth energy solution from ST. The module for the STM32WD15 will be released in early 2021 and the module based on the WD15 will be released in the first half of 2021. Both modules will be certified and based on the same ecosystem offerings we have for the WD155. Having a look at the mesh network solutions available today, the STM32WD is the only ST solution that can address all of them. Bluetooth mesh has been around for some time but only recently has customers taking a closer look at it. The maximum number is 32k nodes. Bluetooth mesh networks have the advantage of enabling the smartphone connections natively and an over-year data rate of one megabit per second. ZigBee and Thread are based on IEEE 802-154 MAC which allows a nova the error data rate of 250 megabit per second. ZigBee is the most mature mesh network standard out of the two. ZigBee has a large following of companies behind these standards. The theoretical limit of ZigBee is 65k nodes even if the largest network we know today counts 700 nodes. Thread is the newest mesh solution. The theoretical limit of Thread is 16k nodes. 802-154 is well based on the IEEE 802-154 MAC layer command. With this standard set of commands any company can implement their own mesh network. Maximum node limit is difficult to estimate and highly dependent on the implementation. Today we focus on ZigBee mesh. What does ZigBee mean? ZigBee is a term that means a few things but here is what we need to focus on within ST. It refers to the ZigBee alliance which has 400 plus company members. It refers to the protocol stack ZigBee Pro 2017. It also refers to the ZigBee 3.0 application layer and associated cluster library. Overall, when a customer mentions ZigBee it means we can support it with the STM32 WB. And here is some exciting to share with you from the ZigBee alliance. In January of this year the ZigBee alliance announced that ST has joined the ZigBee Board of Directors. We are very proud of that. When we look at the entire ZigBee stack offering it has technologies that are as follow. Dot dot this is a technology we do not support within ST which is okay as dot dot is not widely supported. RF4C this is mainly used in remote controller applications at this point we do not support this standard. Jupiter mesh it is an initiative created by the ZigBee alliance to address ITV6. This stack is very new and not widely supported. ST supports 6-loban on STM32 WB. The main points we support are ZigBee Pro which includes the ZigBee 3.0 and smart energy application stacks. With this support we can capture almost all of the ZigBee customer needs today from an application standpoint. We also offer Bluetooth low energy plus ZigBee concurrent operation. This means that the STM32 WB can interface to both Bluetooth low energy and ZigBee networks at the same time. These have always been a drawback to ZigBee networks but with the WBee this is no longer the case. But the biggest advantage we have with the STM32 WB is the STM32 ecosystem. We have multiple software tools and a lot of embedded software with iOS and Android applications available as well. STM32 Qube IDE and STM32 Qube programmer are becoming the go-to IDE and programming tool for STM32 devices. STM32 Qube MX provides customers with the best configuration environment on the market today. STM32 Qube WB includes a lot of examples with Bluetooth low energy plus thread, Bluetooth low energy plus ZigBee and the 802.154 stacks available to customers. We also have numerous functions, packs, that enable audio over Bluetooth, video over Bluetooth and more to come. The WB also interfaces with all of the well-known ST apps such as BLE profile, BLE sensor, BLE star net and BLE mesh. STM32 monitor are off. Brick the ability to monitor and test Bluetooth low energy and 802.154. On the WB giving customers the ability to test their wireless connectivity without specialized hardware or software. Lastly, STM32 Qube monitor power allows you to measure real-time current consumption of your application running on the STM32 WB. Overall, the STM32 WB is back at by the world in class STM32 ecosystem which is the best on the market today. When we look at the evaluation board for the WB, we have the nuclear pack which comes with a nuclear board and the USB download. Discovery boards are coming as well. Ecosystem wise you can rely on a complete tool suite for your STM32 WB. That's all from my marketing presentation. Let me end over to Vita who will enter in technical debates and then long. Thank you. Thank you, Paolo. Well, ZIGB is not new but also definitely not legacy network communication protocol. It has evolved over the more than 20 years and got better standardized recently. ZIGB is nowadays one of the most popular IoT niche protocols worldwide. In the preferred centralized configuration, the ZIGB network has always single coordinator which starts the network, defines the communication channel, assigns addressing scheme and holds full list of neighbors and routers. Typically also keeps the role to permit other devices to join the network. Router is the keystone of the ZIGB network. Routers are responsible for routing, so to find the best way for the message from the source to destination throughout the network. Coordinator works as a router too, but a router-only node is not responsible for the extra job managed by the coordinator. N-device is not responsible for routing and the network extension and is mainly like a user on the network. N-device is always connected to on the single router. N-device is then typically so-called reduced function device. Both router and coordinator are then so-called full function devices. ZIGB stack is split in three main blocks. Mac and physical layer is based on IEEE R&D 215.4. Then there is the ZIGB protocols stack managing the network and transport layer, including security, defining all the routing and providing rules. And ZIGB also specifies the application layer, mainly by so-called ZIGB cross library and defining base device behavior. ZIGB is a low bandwidth short-range communication technology capable to interconnect thousands of nodes in a single network. Now let's have a look on what is the main benefit of the dual core architecture of STM42WB. The ZIGB stack is split between the two cores in the following way. All the parts related to the protocol and which are mandatory to be supported, all the routine tasks and time critical tasks are managed autonomously by the ARM Cortex M0 core and delivered in encrypted certified binary form. Application layer and the application itself is then executed on the CM4S side. So the user has the full performance, full control and is not limited for his application implementation. ST ZIGB solution targets to be a complete ZIGB solution, providing implementation of all the mostly used features defined by the standard and with extensive and extendable ZIGB cost library. All the features listed here can be already found in the SDK, mostly accompanied by an example. If you will have a look at our SDK, so the STM42WB firmware package, it contains simply all the blocks necessary for any development in a single box. Peripheral drivers, medlever, besides RF protocols or also for USD or touch sensing and especially dozens of examples for all peripherals and included medlever. As was already mentioned, the RF stack binaries are provided in encrypted binary form only. And here you can see the actual full set of RF stack solutions available in the latest STM42WB firmware package. Besides multiple variants for VLE and TRED, including global level radio drivers, we do have today also a full set of stack variants for ZIGB and also an interesting combination of being able to operate both VLE and ZIGB stacks in a single application. I would like to highlight here the release notes, which will provide you all details about the available stack options, included features and information how to install them. Inside these release notes, we provide a regular changes log and bug fixes list. We maintain backwards compatibility of our RF stacks. So in case of a bug fix, the user can just take the newer stack and doesn't need to do changes in his own application. If we have a look at the application examples for ZIGB, we do have examples covering all the stack features and most important use cases. The ZIGB examples highlighted are covering the specific scenarios like different network configurations, commissioning strategies, ZB persistent data management, sleep and device implementation and handling and so on. Regarding the documentation, here is a full list of application notes covering both hardware and software subjects of STM42WB and generally RF application development specifics. Those which are highlighted were found useful by every single STM42WB user. We have also already a bunch of ZIGB related documentation. For ZIGB, we have a getting started guide describing the communication protocol basics, stack architecture and its specifics on STM42WB. We have also the ZIGB SDK API reference guide describing all functions exposed to the application core. We have also documentation related purely to our ZIGB cluster library implementation and both to how to use it and also how to extend it if needed. Let's jump on the first demo of the day. We will try to run a whole ZIGD world application. We have today available the PNUCLO WB55 pack as our main hardware development and evaluation platform. It consists of so-called NUCLO board with specific design tunes for RF needs and a USB dongle. On the NUCLO board, besides the target NC area and RF path, completely accessible pinout and simple user interface, you can find there also an STM version 2.1 providing also virtual COM port interface besides standard debugger capabilities. On the dongle, there is no onboard debugger. The target device can be flashed using bootloader via USB type A connector. The dongle can be used primarily as a company onboard for NUCLO. Mainly for evaluation, but still with dozens of benefits and can be used even as a simple RF module during development. As a hello ZIGB board example, we think the best is the simple ZIGB on-off cluster application. We will create the smallest possible ZIGB centralized network by using both the boards available in the NUCLO pack. One board will be the on-off cluster server and the other will be on-off cluster client. ZIGB cluster library is based on client server approach. USB dongle role will be a ZIGB network coordinator and NUCLO will behave as ZIGB router. In terms of functionality, the idea is that once the network is started and both nodes inside, it will be indicated by the blue LED and we will be capable to control the red LED on the USB dongle from the NUCLO board. Before we can start to work with ZIGB, we need to highlight that the boards are coming with GIMP stack pre-installed. So first step should be to install the appropriate ZIGB stack version. Every single application example is accompanied by readme.txt file and lists all requirements in terms of hardware and software configuration. To install the ZIGB stack, every single STM32WB device is coming from our factory, pre-programmed by so-called FUSS Fimware. FUSS stands for Firmware Upgrade Services. It is a secure bootloader always present and available on CPU2, ARM Cortex, and ZERO Plus domain inside the secured flash memory area. The RF stack can be installed then by using SWD or JTAG interface or other listed communication interfaces. Our flashing utility called STM32Q programmer has full capabilities to operate this server upgrade mechanism. Besides documentation available, we have already posted few online tutorials on this subject. So to summarize, to be able to run the on-off cluster example, you will need to flash in both devices the ZB SSD stack firmware binary and on a USB dongle, you will need to program the ZB on-off server coordinator example and on the nuclear board ZB on-off client router example as a user application running on ARM Cortex and 4S Core. We will see the complete ZIGB central network node-joining procedure going through association, transport and linky exchanges, and finally the n-functional execution. Most of the job, let's say, overall process is managed by the ZIGB stack in the ARM Cortex and ZERO Plus Core domain. We will also check out the integrated debug capabilities since, as you could see on the previous slide, the procedures in a robust network communication protocols are sometimes complex. Let's move to the lab and have a look at the example in operation. So we have moved to the lab to have a look at the ZIGB HelloVault example from our SDK package. So we will create a tiny ZIGB network. I have here one STM32WB nuclear pack and as I already said, the out-of-the-box demo pre-ordered on the boards is for BLE. So there is BLE stack and some BLE examples pre-loaded on the board. There is the BLE peer-to-peer server example loaded on the nuclear board and BLE peer-to-peer client example loaded on the USB dongle. So together you have both BLE peripheral and BLE central device which can be connected together. I can just power up the nuclear board and on the phone I can open the STBLE sensor APK. STBLE sensor APK is our main application for all our BLE examples we have in our SDK. It is available on both Google Play and App Store. When I do scan I can easily see that there is the peer-to-peer server advertising and I can connect to it and I can control the blue LED from the phone and when I press the switch 1 button on the nuclear I am getting back to the notifications. But that is not what this demo should be about. This demo should be about ZIGB. I just wanted to show you what is loaded in the boards when you open up the package and we will need to know this functionality and STBLE sensor APK for the second demo later. Before we can download and run the ZIGB examples we need to replace the BLE stack for the ZIGB stack. As we have already discussed for the ZIGB on-off cluster client and server example with ZIGB Central's network setup we need a ZIGB FFD stack loaded at least on the board which will run the coordinator node. But for simplicity we will use the FFD stack on both the boards. I will not show in this demo how to replace the RF stack and eventually upgrade the firmware upgrade services firmware but I will point you where you can find nice tutorials. So if you will just open the STM32QBWBSDK folder you can see the text file called how to program wireless stacks. This will point you to the release notes HTML file in the STM32WB coprocessor wireless binaries folder where you can find a step-by-step guide on how to replace or upgrade the wireless stack. There are also nice video tutorials available just search for STM32WBFUS keywords. The videos will lead you throughout the process. I have here already a Nuklo and dongle with the ZIGB FFD stack binaries installed and on the USB dongle I have the ZIGB on-off server coordinator application loaded and on the Nuklo I have the ZIGB on-off client rotor application loaded. I will first plug in the USB dongle since we first need to have the coordinator which will start the ZIGB network. The blue LED indicates that the network have successfully started. Now I plug in the Nuklo board the blue LED turns on after a while also that indicates it successfully joined the network. Now when I press the switch one button on the Nuklo the red LED will toggle on the USB dongle. On the dongle we have application implementing on-off cluster server and the on-off or toggle commands are simply controlling the red LED state. The on-off or toggle commands can be sent from the on-off cluster client running on the Nuklo board. The complete functionality and how to make it all running is described in the readme txt file related to each example. We can now have a look at the communication in Wireshark. I have here a pre-configured IEEE on the 215.4 sniffer already. It's listening at channel 13. I could read that we are using channel 13 from the example code and let's reproduce one more time. I switch both boards off. I will start the session in Wireshark. I turn on the USB dongle. I can see that the coordinator is advertising the network. I turn on the Nuklo board and I can see that it initiated the joining procedure. I can see the association request response, network key delivery, device announcement, no descriptor request and response, a link key delivery from the trust center and finally when I press the button I can see the on-off toggle commands and default responses. We can also have a look in the debug terminals. Every ZigBee example provides the possibility to propagate debug traces which can help you to see what is happening even without a sniffer and can help you to debug your own code. There are several levels of debug traces that can be changed depending on the situation. So you can filter out some two low-level traces and keep for example only errors or warnings or only the application layer traces. I have here two terra-term windows. One for the USB dongle which implements a virtual COM port directly running on the STM32WB device and one for the Nuklo where the USART2 is connected to the virtual COM port interface of the STM2.1. I will switch off both boards again. In this case I will turn on the Nuklo board first. You can see that it is periodically attempting to join the network unsuccessfully since there is no open network available at channel 13 in my lab. Now I will turn on the USB dongle. The Nuklo joined the network almost immediately. Now I can press the button and see the switch one press events and on-off events in the debug looks. So that was all for the first demonstration and we will move back to the presentation. As a second demo we have prepared the DLE plus ZB combined operation. We speak about so-called concurrent mode. We distinguish between concurrent mode static and concurrent mode dynamic. In concurrent mode static the switch between the protocols in this case DLE and ZB is managed by the user and even though both stacks are present inside a device memory only one can be operated at a time. In concurrent mode dynamic both stacks are operated in interleaving mode. Sure we have single antenna interface so there can be always only one radioactive at a time but it is still possible to quite efficiently schedule the different radio tasks over the time. The most easy scenario is to have a sleepy end device on a ZB site and DLE beacon which is only advertising on the DLE site. The most demanding is then the ZB router which should be always listening and DLE connection where the radio event duty cycle can be changing. What could be the typical use cases for a concurrent mode combining DLE plus ZB? It is all about the fact that any smart device today doesn't integrate support for IEEE ANE254 radio but all of them today do support DLE. So a typical scenario would be to provide a bridge to WIPA network via DLE from a smartphone. Another would be to provide a way to integrate firmware over the update to a ZB device via smartphone especially for situations when the ZB device doesn't have access to cloud. Another use case would be out of band commissioning where the phone would be used to provide the credentials. In our example we will test the first scenario. We will run an example where we will use both our boards Nuclo and USB dongle and on top we will be capable to connect by smartphone. We will have our ZB coordinator running on USB dongle and implementing still the ZCL on-off cluster server. Then we will have DLE plus ZB dynamic mode tech and example running on Nuclo board. It will be both ZB router implementing ZCL on-off cluster client and a DLE peripheral implementing simple service accessible from smartphone. We will have a periodic communication between Nuclo and USB dongle via ZB network. We will simply again control the LED of the USB dongle and we will be capable to control the LED on the Nuclo via DLE from the smartphone at the same moment. Propagation of the command from the smartphone to the ZB network is then just a small missing step. To be able to run this example we need to have a DLE ZB full functional device tech on the Nuclo and the DLE ZB dynamic mode example from the firmware package. USB dongle stays the same as in previous demo. Let's move to the lab to see the BLE plus ZB concurrent mode dynamic example functionality. In the second demo we want to show how to operate the concurrent mode dynamic example. The dongle will run again the ZB on-off cluster server app in coordinator role so this board setup doesn't change and we can keep it as it is from the previous demo. The Nuclo will run the BLE ZB dynamic mode example so we need to switch both the stack and the application firmware. In this case I will show you how to easily replace the stack using the STM32Q programmer GUI. I have here the STM32Q programmer opened. I will connect to the board using SWD interface and there is a special panel appearing only for STM32WB devices. It is the firmware upgrade services panel. I will select the BLE ZB FFD dynamic mode stack and from the coprocessor wireless binaries release notes I could find the target address where to install it. I will run the upgrade. It first delies the old stack and after a while the upgrade will be finished. But to save the time I have here Nuclo which is already upgraded. Now I can program the BLE ZB dynamic mode example binary which I already pre-compiled. When finished I will again turn on the USB dongle first. Once the blue LED is on on the dongle I will turn on the Nuclo board. So now Nuclo again joined the network and in this case you can see that the red LED of dongle toggles every one second. It is because the app running on the Nuclo is periodically sending the on-off cluster toggle command. But there should be also BLE running on the Nuclo. So I will take the phone and open the STBLE sensor APK again. I will do scan and I can see the peer-to-peer server up running nearby. I connect to it and I can now control the red LED of the Nuclo. And at the same time the on-off cluster toggle commands are still sent from the Nuclo to the USB dongle. We can have a look at that using another sniffer in this case from LSS which can receive and pass both BLE and IEEE 800 to 15.4 packets at the same moment. The session was already recorded so we can have a look what happened. We can see both the ARIN250.4 interleaving with the BLE and in this case there is higher traffic on the BLE but still plenty of time between the connection events to be used by ZigBee if needed. So that was all for the second demonstration and let's move back to the presentation. Just a last comment on the concurrent mode firmware architecture principle. If you would have a look in the source code you would find out that the concurrent mode examples are simply combination of standalone single protocol examples. They are showing the code structure are with the same application architecture and the user can still use just only BLE or just only ZigBee in case he has the concurrent mode stack available. It is not mandatory to operate both at the same time. Thank you very much. I will pass the word back to Paolo. Thank you very much for the very interesting end zone. So let's go to the takeaways for today. STN32WP is ready for the mass market now. It's a multi-core, multi-protocol STN32 wireless MCU. It can count on ultra low-power DNA based on the STN32-L4. It has a rich peripherals, memory and packages set with a proven radio and certified protocol specs. And it allows to have a very low BOM cost thanks to integrated balloon, USB crystal less and many other features. The growing portfolio with new parts and modules are coming very soon. The best-in-class training materials with a wide offer of massive online open courses available today. And finally, the best-in-class STN32 ecosystem. Everything to get started available now. Let me give you a last very important message. STN32 goes wireless with you. Thanks to the huge investment ST is doing on the STN32 WX series. 2.4 Gigaerts, Bluetooth, ZB, Thread, Point-to-Point, Point-to-Point, or Mesh. Ultra-wide band technology, thanks to the latest acquisition of Homelocks. STN32WP has a protocol with the incoming launch of the World Wide First, Lora System on Chip. And finally, NarrowBand IoT and LTE, modules offering coming soon as well. All are reached by strong Arab capabilities, with strong focus on security and large offering in terms of flash ramps and packages. Ten years' lifetime commitment renewed every year, no matter what. All supported by the best-in-class ecosystem ever. Thank you all. Thank you, Vic. Hope this webinar has found your interest.