 Okay, we talk a little bit about how to enable the clocks, but I think now it's also time to look on the rest of our main.c, where are the most important initialization, which we have. The one of this initialization is the clocks. In our last example, which we do in our GPO example, we said let the GPO in the default state, we set the microcontroller clock here on the 16 MHz, then now we can look inside our IDE how this settings is reflected inside our code. Okay, now we are in our IDE, in my case the IR, and our interesting function will be the system clock config, then we can look into this function, the definition is a little bit lower in our main.c file, what we can see. Definitely we have here two structures. One is the structure defining the source of the clocks, here the oscillators, and there is the clock initialization structure, which will configure the main buses on our device. Then we can also see that we enabling all clocks for the PWR. The PWR is necessary because somethings need to supply our clock domain, also the microcontroller. Then we need to select the correct voltage scale, usually the voltage scale limits the frequency, on the voltage scale too we can reach the maximum frequency. Then we see that we using the OS init structure, we initializing the type of the oscillator in our case HSE, we enabling the HSE, we setting the calibration value, and we telling that we don't want to use the PLL, that it will be no PLL used, which is correct, which is how we want to work. Then we run the OS config, and we know that the HSI will be running. And then we use the second structure, we tell this structure that we want to configure the HCLK clocks, the system clocks, and the APB1 and the APB2 clocks. First we here selecting the clock source for the system clock, which is HSE, HSI, sorry. Then we selecting the divider for the AAHB clocks, and the dividers for the APB1 and APB2, and then on the end we calling the clock config. And here is last important parameter, here is the flash latency. This is very important parameter, in case that you setting this clocks on your own, you not using the cube mix, you need always to set here the correct parameter. Because the flash latency depends on the speed of the core. It's usually the flash latency limits the speed of the reading from the flash. Because the flash is usually very slow memory, and flash runs to roughly at maximum 20Mhz. In case that your core is faster, in our case can be more than 80Mhz, then we need to give to the flash more time to provide us the data, in case it's called the latency. And for each frequency we can found which latency we need to set. This description is in the reference manual, there is the table describing for which voltage and for which voltage range how many white states we need to use. In case that you use the higher number, the performance of the flash will be lower, but it will be no problem. But in case that you accidentally select the lower value, then the result can be unpredictable and the micro can end in the fault. Then be careful on this parameter. Ok, this is the flash latency, and then is the initialization of the sys-take and of the NVIC. About this I will talk a little bit later after this clock initialization. We can see we again using here the structures. If we want to know how the structures are defined, we can again here look inside the definition. What are the structures parameter here are again the references. In case that we use the PL, the situation will be more complicated. We can now try to do this example also with the PLL. Then we again open the same project in the kubemix, and we change the clock source to for PLL. Ok, I think we can do the trick. Here we can set the 84 MHz, that's ok, it's usually the kubemix asking us to change the source, then I allow it. And now we also using the PLL. Ok, I can save my project, I can regenerate the project, I think it's not necessary to open because I have already opened my project. Then we look inside the IDE. Ok, in the IDE we can see the change, the oscillator type is still the HSI, we enabling the HSI, the collaboration value is still the same, but now we also enabling the PLL. We setting the source of the clocks for the PLL that it will be HSI. We set the parameters for the PLL that we will divide the frequency of the HSI by 8, then multiply it with the 64 and then divide this frequency. And here also in the clock in extract we setting the clock source as the PLL. Then you can see that the kubemix handle for us this configuration in case that you want to change some things you can do, but always be careful what will be the result, sometimes it's better to let the kubemix do this for you. And on the end you can see he also set here the correct flash latency which corresponds with our parameters, if I look into the reference manual. Then here I running on the 3.3V which is here, I'm running on the 84 MHz and for this I need to have 2 weight states, then it corresponds here with the flash latency too. Then don't forget on the flash latency, it can be very dangerous, nobody can predict what will happen during the code execution. Okay, and why not to test the latency check, definitely if you compile the code and build the code, flash it, then I expect it will run how we configure it. In the last example it was when the button is un-pressed, the LED is on, when we press the button LED is off. If we stop the debugging you see we are still in the code. Then now we can try to simulate the fault state, we can here configure the wrong weight states to see what will happen. Okay, I put here 0, I will make my code, yes it's okay, I will flash it and what will happen. Definitely in my case the LED is not on, it's not react on the button, then it seems that something is wrong. If I stop my code you can see in this assembly I am on the very weird area, which is not in the flash, which is not even in the RAM. So usually the micro is completely, completely stuck and it's in the state called lockup, which means that I had the fault in the fault and micro simply stops. Then it's something wrong. Normally in this case sometimes it's first indication that something can be wrong with the clocks. Then don't forget to set correct weight states for your flash memory in the clock initialization. Then here return the weight states to 2 and everything will be okay.