 Welcome back! So after being able to enable the basic peripheral from an existing code example, now we'll start from scratch, let's say, at chipset level, and we will build back a P2P server application. So let's start. Okay, so in order to achieve this endzone, we'll go through various steps. First, we initialize the hardware. In step two, we'll move into the interesting part. Advertising demystification and playing with BLE API to move to advertising. We'll generate the code and we'll be able to play. And then some bonus track to add logs. What do you need? So you need the same, exactly the same requirement as the first click and go. So that means you still need to get access to the STM32 WBA, 55 nuclear boards, the smartphones, and of course all the software prerequisites that are available on the link on the video YouTube page. What is the purpose now of the endzone? In the click and go, we are starting from an existing code example. Now we are willing to start at chipset level to build a basic P2P server application. The focus of this first endzone, endzone one, is really to put the device visible and connectable from any smartphone. In endzone two, on top of being connectable, you will be able to exchange some data through attributes. So let's unpack the board and start. Just aware of all the material we used and all the steps which are described in the coming video, are extracted from STM32 wiki pages. If you go to Google and if you enter for STM32 WBA wiki, the first link will allow you to go to STM32 wiki pages associated to wireless product. So here, as you can see, there are various articles about BLE, ZigBee, and thread. The endzone we are playing is the one associated to STM32 WBA series, how to build using QBMX. Again, this wiki page is more than useful in order to understand some BLE concept and overall software architecture. And this is a page we will use, or at least you can refer to later on, with all the details that we will play right now. Just for witness, the legend associated to the video. This icon means here we are dealing with theoretical slide. This means we are adding some code and we will build and flash to the board. Ok, so step one, hardware initialization. As in phases already, during the click and go and how to start evaluation, using STM32 cube and QBMX, you can start from code example, typically the click and go, at board level or at chipset level. And this is our focus of the day, starting at chipset level. And this is exactly what is described in the wiki page. As a customer, let's say I want to build my own application, my own stuff based on ST chipset. So let's start from chipset level. Starting at chipset level means, ok, what is the complete journey? I need first to initialize the hardware, the peripheral, the clock tree, and at the end I will be able to focus on the application itself. Configuration of the BLE, the advertising series characteristic, and at the end being able to generate the code and build. This is definitely the focus of the hands on one and two. Focusing on BLE aspect, demystifying a bit some concept and playing with the board. So yes, we will start from chipset level, but to ease our overall job, we will not start from scratch, but we will use an IOC file. The IOC file are the files used by QBMX to generate the hardware configuration. So on the YouTube video link, there is a link to access to this IOC file. So please, access to it, copy it to your own local directory, and then we'll be able to start. What is the purpose of this IOC file? The idea again of the hands on is really to focus on, let's say, the BLE stuff where you will have to put your application. The idea of the IOC file is that it's already preconfigured to enable all the RF block to allow later on to enable the BLE stuff. So again, this is used to ease your life. Let's start and let's play again, and let's play together to import this IOC file. So we'll all open QBMX, and I will do exactly the same to import my IOC file. So let's open QBMX. I will start file. I will go through import. Import an existing QBMX configuration file. Then it will look at all the IOC file. Then I will browse to the repository where I have stored this IOC file. Then I click to open, finish, and then QBMX tool is starting to generate the overall hardware configuration. At the end of this configuration, which isn't going on my laptop right now, you should get this nice screen with the pinning which has been enabled. And the fact that all the associated hardware block has been enabled to later on being able to enable the BLE stuff. So let's have a look at what is going on my tool and write. Here I've got the QBMX panel, and indeed I have now the hardware configuration which is done, STM32WBA55. And if I click there to AZ, what I will find? I will find that already some blocks are in green, meaning that those blocks have been enabled. And why they have been enabled? Because those blocks are mandatory to later on being able to activate the BLE. If you want to have more details about why I need RTC, why I need RCC, you can have a look to the wiki page where you will find some rational. Okay, good. So we've got our hardware initialized. Let's move now to advertising and Bluetooth Low Energy application configuration. So let's open back QBID. Through QBID you go to AZ. Here again you have all the hardware IP which has been enabled thanks to the IOC. And what we are willing to do now is to enable the WPAN. So you click to WPAN. And what are we willing to do? I'm willing to build a basic peripheral. I want to create a peripheral and a GAT server application, a basic device which is capable to exchange data with a smartphone. So you click there and then you can start to configure the BLE settings. Okay, so here we have so enabling all the hardware IP. We have saying that we want to create a basic peripheral. I'm ready to build a basic peripheral. As we are dealing with Bluetooth Low Energy, let's maybe step back with a bit of theory and understand some concept. Here a BLE stack with GAP, GAT and ATT layers which is the OS stack. The GAP layer is defining let's say the roles that the device will play in the topology. In general there is a peripheral and a central. Peripheral is a device which is advertising saying hello I am here and the central most of the time is the smartphone which is looking and scanning and looking to connect to the peripheral. This is the role defined at GAP level. At GAP level, this is another angle. This is the way that define how we want to exchange the data. And here there is two let's say main role. The server and the client. The server which is the one having some data to share. So typically your device. And the smartphone which is the client which is the one looking for data. And that's true in general role of things. Central is acting as client and peripheral is acting as server. Okay so now let's move to BLE configuration. What I want to do I want to initialize some settings of the BLE advertising. The first step before being able to connect is advertising. So I want to be discoverable. Okay let's have a look about the first advertising configuration. So in advertising configuration I can set different settings. The advertising type meaning okay I want to be connectable or not. If I want to lose the white list. And the advertising interval which is defined with a million max. Just to give flexibility to the stack in order to put some let's say more connection if we are dealing with a multi-slot use case. So advertising type. We are willing to accept all the connection from any smartphone. That means we are not using privacies or advertising if literally is disabled. Advertising interval pretty simple. Here we'll deal with one connection. So the main plus max divided by two will give us the advertising interval. And the value here is in milliseconds. So for time being let's open back QBID. For timing we use the same settings. We keep the default settings. That means we will advertise at almost 100 milliseconds. What does that mean? Here a basic timestamp about a legacy advertising frame. So advertising mean I am a device saying hello I am here. Just broadcasting some data over the year while the smartphone is scanning. The specification will tell you that you need to send an advertising event saying hello I am here on three channels. 77, 78, 79. And you have to send those advertising events at each advertising event. Which can be from 20 milliseconds up to 10 seconds. So that means every typically 100 milliseconds in our case I will get an advertising event. That clear there is a big link between connectivity latency and power consumption efficiency. Advertising every 20 milliseconds will consume much more than advertising every 10 seconds. But at the end being able to connect 20 milliseconds if somebody is entering in the room with a smartphone it will be visible in a few clicks and being able to connect quickly. So at the end here this is a draft of legacy advertising. So that means we have burst of advertising which is very basic. 31 bytes, roughly 3 milliseconds every x milliseconds. So every x advertising interval. But for sure our product supports much more than basic legacy advertising. We are supporting typically advertising extension. We are supporting as well the periodic advertising which is used for the BLE audio stuff. So okay this is just for legacy and we will focus on legacy but we are supporting much more. Okay after the advertising settings let's move to the payload. What I want to advertise over the year. First let's select BLE advertising okay. We will have to say what we want to push over the year. We select the advertising type and we'll see later on in coming slides what is the meaning behind. But I want to advertise local name and manufacturer data okay. So we select yes to local name. We put a local name okay. So this will be the name broadcasted over the year. And then as well we'll push for some manufacturer data. Please keep in mind that local name must be equal maximum to 10 bytes okay. This is a constraint from the tool. So please make sure the local name is below 10 bytes okay. So let's do it together. So I'm moving now to cube ID. Let's enlarge the window here. So I want to advertise a local name. Yes what is the name I will put. So I will put my name. So I am Dominique. So I will put DOM STM32 for example. So still below 11 bytes for sure. And I will have to advertise some manufacturer data okay. So you have to say yes I want to put some manufacturer data. And here please the number of item to be sent is 12. And I will explain later on okay. So back to the slides to make sure about the settings. You should have a local name below 10 bytes. And manufacturer data with maximum 12 bytes. Put 12 here please. Here we are willing to advertise some data. Some theory here. How an advertising payload is built. So first again considering legacy advertising. And advertising PDU is up to 37 bytes right. On those 37 bytes 6 bytes are reserved for the BLE address. That means you have up to 31 bytes for the advertising data. The payload that will be transmitted over the years. Say hello I am here. And this advertising data is split in what we call advertising element okay. So within an advertising payload you can have different tip of the element. The ID element are specified by an advertising type. And the specification is telling you that there are different advertising type. Local name, manufacturer data. And associated to an advertising type you've got the data and the overall length. So here typically. I want to broadcast over the year P2PS 01. I want to say this is a local name. So I will put the tag for local name which is 09 and the overall length is 08. At the end if you look about some logs on smartphone. This is what the smartphone will be able to see over the year. The first 8 bytes are associated to a local name which is this hexadecimal value which is P2PS 01. So at the end pushing over the year advertising element you can push for what you want. Temperature, name, hello world, what you want. The only thing you have to do is that you have to specify an advertising type. Local name, manufacturer data. And this is a way for the smartphone to detect. But behind this I will get 8 10 bytes associated to the local name. But for sure for local name you can put a name or temperature up to you. It's you that is designing the application. So the manufacturer data. Here we have put 12. This is basically to adjust and adapt to a basic protocol which is used by our ST Toolbox application. In order to be able to display a nice ST logo detecting OK. This is the ST devices and then later on to display LED, push button and so on. So this is purely applicative stuff. OK, so back to the QBID. We have defined manufacturer data, local name. But there is still something to be done. In configuration you should get at the bottom gap device name. OK, please here put the same content as put in the local name. This gap device name let's say is a specificity used by iOS devices. That copy this device name on their cache at the first connection. And so at the second connection whatever you will push over the A and the advertising frame. The iOS will detect OK. I know this MAC address. I know this device and rather than displaying the BLE advertising payload. The iOS will display the gap device name. So to avoid any confusion let's put here the same content. OK, so back to the slide. I'm putting exactly the same and the rationale behind again it's due to iOS. Let's say Constraints. As you can see on your QBID you should still get a yellow warning for the platform settings. And this is something that we have to set to anticipate log activation. Let me open back the cube. Platform settings in the yellow. I want to enable the logs later on over use art. And it will be on use art one. OK, so at this stage we have defined all the BLE settings. And as well the platform settings in order to enable the logs. So what's next? Next will be the code generation. OK, so now let's move to code generation. So pretty simple with QBID. There is this little wheel on the top that allows to generate the code. So let's move to my project and let's generate the code. OK, so now the code is on the generation. So at some point at the end we should have the code now generated. So the next will be application code. But before moving to application code itself, let's have a look about the code generated. OK, so here the code now has been generated. So you should see some files here in the project explorer. If you go to WPAN, APP, APPBI.C, and if you scroll down a bit you will see that indeed the advertising payload is the one that I have set using the QBMX tool. OK, so now that means we can move to application code. Application code indeed using QBMX for the time being we have set the advertising payload, the advertising interval, the configuration itself. But now the application needs to ask to the chipset, to the stack to move to discoverable. So to advertising using the payload that we have defined. So we have to build and to add some code, some application code. To do this, please refer to the cheat sheet which is part of the link of the YouTube video in order to copy past the right code. So let me open. The first one we'll have to copy is so in the section ends on one. Code need to move the device in advertising. Let's copy this code. This code need to be copy past in the code, add user code, begin, APP BIani need to. OK, so let's move to the code, scrolling a bit down. Here we are, user code begin, APP 267. I copy the code. Now it's imaging that your device is visible. Fine, great. You connect and you disconnect. If you are disconnected and if you won't move back in advertising, you have as well to add some code, which basically is the same. Application need to ask to the stack to move back to advertising. And this need to be done under the section user code begin, even disconnection complete. This is the event raised by the stack to the application saying we have been disconnected. So again, let's move back to the cheat sheet. We copy the code, which by the way is exactly the same. So I move back. OK. And looking at this connection event, here we are, I'm disconnected. And under the user code begin section, I pass the code. OK, we're done. So now we have built the application code. What's next? The next is to build. And to build, you have to click on the hammer here. So let's start to build the code. OK, I click on the hammer. The code now is on the build. OK. And next, what we'll have to do is to flush the board. Prayer to flush the board. Of course, we have to connect the board to our laptop. So let me connect the board. So this is my nuclear board that I need to connect over USB to my laptop. OK, board is connected. I'm ready to play or at least to flash. So my smartphone is not with around. OK, so the build now is not yet completely over. Take a bit of time today. Let's wait for the completion. OK, build is done. OK, so now next is to flash the board. And to flash the board, I just need to click here on the green arrow. OK, which is the application you are willing to flash. Yes, this is the WB-55. What is the bigger you are using? It's ST-Link. Yes, apply and go. So at this stage, the ST-Link will take control of my board. OK, I will flash. So the bugger is now controlling and flashing. So download in progress. OK, great. Now the download is done. So my board here has been flashed. OK, now let me open my smartphone. So I will open the needed application. So let me display my smartphone here. OK, I'm opening the ST Toolbox application. Then my smartphone is able to discover my device. So as you can see, my smartphone is able to detect DOM STM32. I can even connect to my board. OK, now I'm connected. I'm connected. OK, but what I can do? Nothing. We have not created the attribute table. The second end zone. So in this chapter, we have been able to connect. And in later section, we'll be able to exchange data after creating a database. So first, I hope that you all succeed to make your device discoverable and then to connect to it. OK, so you hopefully all succeed to connect your smartphone to your board, to your nuclear board. Let's have a bit of look about debug capability with an extra bonus. Let's add some logs to our application. How to do this? It's pretty simple. You just need to open back your Cubemix Tool. OK, so let's do it together. You just need to click back on the IOC file. So I'm opening back the IOC file. OK, so it's processing again in order to be able to display the tool. And as soon as the tool will be ready, we will just have to enable the logs. OK, so rendering is on the way. So OK, Cubemix is there. I just need again to go to the WB panel. OK, let me extend this. And inside configuration, this is where I would be able basically to enable the trace application logs support. Disable, I just need to enable it. OK, fine. But what I need to do now, I need to generate back the code. So either you go to control S in order to save or you click the line below just to make sure the first line enabled has been taken into account. OK, and you generate it back by the wheel. So on my site, OK, enable, let me control S. OK, it asked me if I want to regenerate the code back. Yes, I want to generate it back. OK, so new code on the generation. Good. And then what I will have to do. Of course, before seeing and being able to see any logs, what we'll have to do as soon as the new code has been generated. OK, which is now the case. I will have, of course, to build back because you have just changed some settings. So I need again to build back. So I click again on the hammer in order to build back my application. OK, so it's building back. As here, I've changed a .h file is building back the full application. So again, we take a bit of time. OK, and as soon as the build will be done, I would be able to flash. Build is done. So now let's flash the ball. Again, the arrow right here. So let me flash my ball. So again, I'm flashing to my nuclear ball. OK, so now what I need to do. Basically, the idea is to build and to see some logs. So that's why we have installed the Terra Term. So I still have my board, which is, of course, still connected to my PC. Then I can open for Terra Term. OK, let me open the basic Terra Term. OK, so I open the Terra Term window. The settings needed for sure. First, I have to open the right comport. So the comport is, for me, will be the 123, I guess so. OK, I'm connected. OK, so now what I will do in order to see the logs, I will basically press the reset button, my board. So here, if you see the boards, OK, if I press the reset button, which is just here, as you can see, I have some logs here. Let me press it again. Again, I have some logs telling me that the stack has been initialized and so on and so on. Again, if I open my smartphone with the STL toolbox, OK, let me open. OK, so if I mirroring my smartphone here, so here, let me display on the right place. So here, maybe, my smartphone is capable to see the boards. And I can try to connect. So I will connect. I'm connected. And as you can see, I receive some logs telling me we have been connected. The connection interval is 30 milliseconds and so on. So here I've got some logs input about the connection settings. So here, just by setting a flag through the cube ID, we have been able easily to add some logs in order to ease code understanding and debug capabilities. OK, so hopefully you all succeed to connect your smartphone to our Nucleo WBA55 board. So here, thanks to the powerful STM32 cube ecosystem, we succeeded within a few clicks and line of code to build a basic device disk or rebel. OK, so now what is next step? Next step will be with Sebastian to build an attribute table service characteristic to be then able to exchange some data from your smartphone to the WBA55.