 So, if we go back into our IAR software now and we right click on our audio player header here on the left hand side and select options, we're looking for the C C++ compiler and then we want to click on optimisation. By default the system is always optimised for size. So we're now going to change it to be speed so that we get the fastest code running to keep us in sleep mode as long as possible. So if we okay that and if we do a project rebuild all then we wait for everything to be reprocessed for speed optimised from the compiler. It takes a bit of time because it has to go through all the files and all the libraries again to reprocess everything. There we go. So we can now go project download and download active application again into our target board and press our reset button and I am getting about 7.5 to 8 milliamps in run mode and about 6.2 milliamps in stop mode. So we've saved a bit of current consumption to what we had earlier. So by changing the option from size to speed we've improved our current consumption but this will have a negative impact on our flash consumption. So there is a tick box there to say that there is no size constraints for the flash so that means you've got a device that's got plenty of flash because the code impact of switching from speed to size can be quite significant. So the compiler reprocesses every single library and optimises every single library so this will run as fast as possible to make sure you can go into sleep mode as quick as possible. This can have as you could see there quite a negative impact on the size of the actual code that we've now got inside our application. So this is our screen capture so I was about 6.2 in stop mode and about 7.5 to 8 milliamps in run mode. So again this has made some savings so it actually has saved me something in the stop mode there compared to what my screen is showing and it saves slightly more than 6% probably more like 10% in play mode by changing the compiler settings. You can also optimise every file individually in the compiler so you can select each file name and then right-click and optimise each individual file by size or speed so you have the flexibility inside the IAR compiler to actually override the inherited settings from the top of the project folder for each individual file. So last option we've got is the clock itself so we can actually have a look at the clock and see what we can do with the clock structure within the STM32L4 family. Big question why do we need to run at 80 megahertz? Our audio is in real time so therefore it's not specifically fast. We do need to keep our 48 megahertz to keep our USB functioning and our 11.29 megahertz to keep our audio functioning correctly but we don't need to run the rest of the device including all the PLL structure at 80 megahertz so we can actually slow the clock system down of the rest of the device just maintaining our USB and audio peripherals and that should be able to make a bit more difference to our current consumption. So let's have a go at that. To do that we need to go back into our cube project and go to the clock configuration tab. We need to make sure that our USB and SEI peripherals state at the correct speed when we reduce our system clock from 80 megahertz to 60 megahertz. Then we'll generate the code, load it into the IAR system, rebuild it, program the board and then have a look at our final current consumption readings for the project with the clock running a lot slower.