 and I didn't notice it, but it's already given me a warning to say, please check the LP design to get consistency. So this is a strange bug in the tool at the moment, because if you remember, we actually did that. We did click on check LP design, everything was fine, and it's still warning us to do it. So this needs fixed, this will be fixed hopefully at the next revision. This is a redundant warning. Do we still want to generate code? Yes, we do. So it'll go away and it will generate the project for us. Okay, and so now we have the project here, and we have some extra, an extra directory in our code tree now called LP BAM. And in here, there's the LP BAM app, and this has the configuration for our scenario builder and our configuration. And if we look at the file LP BAM, LP BAM map.h, this is the header file that gives us the prototypes for all of the LP BAM functions that we need to set up the DMA controller and the link list memory block in the way we need them. So for example, there's the LP BAM init, the scenario init and scenario d init. So when you stop using it, scenario build builds all of the individual code configuration settings that we need to store into memory. And finally, scenario start and scenario stop. So these are commands that we'll be using in the code to actually build our DMA transfers. So first thing we need to do is to go and edit our main.c file. So it's under core. I've already got it open actually, but just to show you where it is core source, sorry, main.c. Okay, now the file I just showed you, the include file, needs to be included into main.c. So if you look in your cheat sheet now under the LP BAM hands-on under cube ID, you'll see all of the code edits that I'm gonna make over the next few minutes. The first one is to include this include file. So I can click on copy code and then go to the main.c. And I need to paste that inclusion into the private begin includes, which is user code begin includes, which is line 24 or so, so we stick it in there, okay? Now I need a variable to store the data, the data sequence. And I also need a variable for the scenario handlers. So we copy the next block of code and that needs to go in the private variables declaration. So we go to user code begin PV and we need to paste the code there. So what we have, we have the DMA handlers and then we have the data buffer for the ADC data. And now those functions that I highlighted to you in the header file, we actually need to use those functions now. So in the user code begin to block, which is down here in this block of code here, you see that first of all, we have some standard cube MX generated code to initialize the LP, DMA, the GPIO and the instruction cache, but we also need to initialize our cues. So we use those functions that are included in the header file. We paste them in here. Let me just put a bit of spacing it so we can see what we're doing. So we init the LP BAM mode, we initialize the scenario, we build it and then we point the DMA handlers to the specific instances of the DMA channels, so channel zero and channel one. And then we link the scenario to this handlers and then finally we start the scenario. The scenario is the collection of DMA configurations, the link list as it were. Okay, now it's important, as we said, if we're trying to conserve as much power as possible, that we turn off the debug block. And so, and then once we've done that, we enter this stop mode so that we turn everything else off and just process the DMA transfers. So there's a block of code to do that and we put it after our last set of initialization or so we disable the debug in stop mode and then we enter stop mode too, okay? And this point, music coming in too, yeah. And it's just, if you look in the cheat sheet, it gives you a warning to say, make sure you stick it in the user begin to and user end to blocks because each time you generate the code, it will rewrite the code except for the blocks of code that you've added in between the user code sections, okay? So as Jeff said, it's important to make sure we put it in the right place. So we now need to make a few alterations to the actual scenario files themselves. So if we go to LPBAM scenario build.c, which is under the LPBAM directory. What we need to do here is we need to declare the variable that we used in main.c for our data sequence. We need to declare that in this file so it can be seen. So it needs to be cleared as an extern. So if I do that and I paste it into the user code begin external variable section or EV section, which is around here, there we go. So I'm declaring this variable as an extern. So it can actually be seen by this piece of C code. But if we go back to where we were, just to remind ourselves, because I've got lost, we basically declared the variable and in the scenario build.c, but now we need to, again, interesting question why we're doing this, but it is the way it is at the moment. We need to enable the power supply for the ADC. And you would say, well, okay, it's in the scenario that we've just created. Why do we have to create it in the ADC init file? So I think all I can say is it's early days for the tool. I don't think we should really have to do that, but we do right now in the code that we generate. So let's go do that. So we copy that line of code, we go to lpbamscenario.config. And we need to be very careful where we post it here because the function we're looking for is mxadcmsp init. There is another ADC init, but it's this specific one we want. And so it should be around line 449 or thereabouts. So if I scroll down, okay, so this is the function and it needs to be in user code begin msp init zero. So begin. So we want to put it there. And it's important we put it there because it needs to go between the user code begin and end blocks, okay? If we don't do that, when we regenerate the code later on, it will overwrite our changes. So we need to put it in there. And that is turning on the power supply for the ADC. And now we also need to turn off the timer or turn off the PWM from the timer. And we do that in the transfer complete DMA queue. So what I'm referring to is there's a function in the code with a callback that gets activated when we hit the transfer complete. And we basically want to stop the timer at this point. So I copy the code and then find the function which is around 764, so down here somewhere. So this is the callback. So it's ADC DMA transfer complete callback and at this point just turn off the timer. Now we come to the, so let's just save all these files so we don't get completely lost. So if you click the save all button up here on the top left, that will save everything. It will automatically save them when you go to build so long as QBID is configured that way, but it's safe just to save them all at this point. So now we need to edit the linker script and we go to the flash version of the linker script. We'll click on it. The area we're interested in is this section here. Now, just like Jeff mentioned, you're using the link list in SRAM 4, but it's even more important for us because we are turning off power to everything else when we go into stop two mode. So the link list specifically needs to be, and the data buffers need to be in SRAM 4 section. Now, for a normal application, you wouldn't put everything else in SRAM 4. So you'd have to make sure that your specific bits of code were located to that section, and you normally use attribute section keywords, and we show how to do it here. However, in our example, it's not a big example. So we can run absolutely everything from SRAM 4. So we just simply modify the linker script to basically put everything in SRAM 4. So that avoids us having to use these attributes, but we do mention it and we do show you how to do it. Let me just copy this block of code and replace what's currently there. So it's this section in the memory linker script, and essentially we're just basically just limiting where the RAM can go. Now, at this point, we need to hit the save button and build the application. So it's good practice to make sure that you're selecting the top level project name so that you know which project you're building. Select that and then click on the hammer button and build the application. So no errors, no warnings. So assuming that it built okay with no errors and no warnings, we want to program the target, okay? And I find the best way of doing this is to make sure that we don't have the power shield connected. So we've just come through a lab with Anders where he was using the power shield. So I would remove the flying lead, just the power one is fine. You don't need to remove the ground and reinsert JP5 so that the board is being powered by the ST link because otherwise the ST link won't be able to find the target micro control, micro processor, micro controller. So pull off the power shield, flying lead, reinsert JP5, and then we can go and we can start a debug perspective if we go and click debug as and then Cortex M C++ application. We're not actually gonna debug this, we just want to erase the chip and program it. We could have used the run option as well, but I'm using debug just so we can see that it erases and downloads the board. Click on okay. And down here, you should see it connect to the target erase and then flash device. So it's nice to see as a comfort that it downloads and verifies and it says downloaded and verified successfully. So we swap to the debug. So because we're in the debug perspective, it's obviously starting in the first line of main.c which is halinit. And at the moment, we can actually step through code because we've not yet turned off the debugging connection. So I should be able to step over this halinit routine by clicking on the step over button and it does it steps over. So right now we are in debug mode, but if I hit the run button or the resume button, then it will run, but then it will start to say target is not responding. We're trying. And the reason is is because we actually turned off the debug block in the software, as you remember. So it does that for a while and then gives up basically drops the connection. So we need to, we can close the debug perspective by clicking on the debug icon here and clicking right click and then close. If you still have it open. But what we've done now is we've programmed the board. Okay. So the board is merrily running away on it. It's doing its stuff. And now is the time where we want to actually use the power shield to measure the activity of the board.