 Welcome to these STM32 tips about embedded bootloader investigation. All the STM32 are an embedded bootloader inside the flash system memory. These bootloaders allow you to connect to your target thanks interfaces like Usart, iSquare C, iSquare S, USB or CAN. The boot mode of your platform allows you to boot on user flash where your code is located or in RAM on the last point on this embedded bootloader. Depending on the port, the boot mode could be defined thanks. Boot to zero pin level, some values option by it, but also it could be linked to the empty flash check mechanism. Boot mode is defined in the reference manual of your MCU, but you can find also all the activation pattern in the AN2606. For this presentation I will use a Nucleo G474 array, but the principle remains the same for all the STM32. First point is to check in the AN2606 what is the pattern to activate the bootloader. Here it was the pattern 14. Then at the beginning of the application note, you've got the full description of those patterns. In our case, we've got four possible configurations. So I will use the first one. I should ensure that the boot lock option bit is set to zero, the end boot one option bit is set to one, the boot T zero pin should be set to one, and finally the end software boot zero option bit should be set to one. Let's check this configuration on our target. So let's check the configuration of our board. First I load SKU programmer, then I connect my board. If I refresh, ST-Link should be detected. We've got a serial number, then I connect to the board. I want to check the option byte, so I click in option byte tab. The first one is boot lock. This one is part of security mechanism, so I will find it in the secure protection here. We can see that boot lock bit is not set. Perfect. Let's check the two other one, end boot one and end software boot zero. This one would be in the user configuration. Then if you scroll down, you can see end boot one, which is set to one, as we expected, and end software boot zero, set to one also. Perfect. So the last point we have to ensure to enter in our boot loader is to set the boot T zero pin to one. The information where the boot T zero pin could be found in the user manual of your Nucleo. But you can also find this in the blister. Here you will find the boot T zero pin on the pin seven of the connector seven. On this same connector, the pin five is to VDD. So if I create a shortcut between those two pins, I will set the boot T zero pin to one. Let's do this now. Okay, now I reset. Now I enter in the boot loader. But the next question is how to be sure that I really activated the boot loader. Let's now try to answer this question now. You can ensure your boot loader is properly activated by checking the program counter value. This one should be in the range of the system memory address. This range could be found in the reference manual of your MCU. So let's check together the program counter of our target. Just need to connect CPU. And here you can see that the value of the program counter in the range of this internal loader. So it's working fine. If now I set the pin boot T zero to around and press the reset button, then we can check the core. And you can see we are in the range of the flash. So really we show the basic things just to check if the boot loader is properly activated is to check the program counter of your target. Now we know how to ensure the boot loader has been properly activated. The next step is to communicate with this boot loader thanks to selected interface. In the IN 2606, you will find the list of those interfaces on the associated pinout. For my G4, I can communicate through that one user 2, user 3, I2C2, I2C3, I2C4, SPI1, SPI2, and USB. What should I check if I fail to communicate some of the selected interface? My first advice would be to create a simple application which communicates through this interface. This will allow you to check the hardware path in your design. Another possible issue is an activity detected on another interface, and the boot loader is waiting on it. As you can see on this diagram extract from the IN 2606, the boot loader is scanning the different interface. But as soon as an activity is detected on one of them, it jumps to an infinite loop on this interface. So if you are waiting on I2C2, and if an activity is detected on user art, it will jump in a loop on the user art, and you won't manage to communicate through your boot loader until the next reset. For the scenario of this on-zone, we've got the boot loader activated on our target, and now I will communicate with it with the user art 2, which is in fact through the pin PA2 and PA3 which correspond to the virtual comport of my nucleo. For this showing, I managed to communicate with my boot loader. Then I will reset, and I will just manually toggling the pin PA term before doing anything. And then I will try to communicate with user art 2 again. And let's see what happens. So we know our boot loader is already started. So now I will just select the user art interface. Only one comes earlier, which is the virtual comport of my nucleo. And then I connect. It's a bit slow, but it was working. My memory is reading. I can communicate with my embedded boot loader. So now I will disconnect and reset my board. That means the boot loader is waiting on all the interface. Now I will manually toggle the pin PA 10 to 1 and set it back to 0. And now let's try to reconnect thanks user art 2. There is some issue. You see that the boot loader doesn't answer. It is not working. Let's try to explain first what is the issue. In fact, the answer is simple. A simple toggle on PA 10 pin drives a boot loader to start communication on user art 1. While we want to communicate in user art 2. And as we said, as soon as one interface is activated, the boot loader doesn't scan anymore the other interface. So let's explain the observed PFO. Here are the tips to find which boot loader interface has been activated. If you still have the software debugging link on your target, you can check the register of each IP to understand which interface has been acialized by mistake. This could be Dan Song's QPro programmer. There is a graphical version in beta, but I will recommend the common line. Information needed for this I identify all the potential interface thanks to IN 2606 and to get the memory address on the register size of those interface thanks to the reference manual. As previously stated, in the IN 2606, I can find all the interfaces of the boot loader for the G4. For the base address and the registers, I can find this in the reference manual. There is a special table with the memory map and peripheral register boundary address. Thanks to the information collected, we can build a common line to dump all the register content for each interface. The first line shows you for the three users, then for the three I2S interface, the both SPI and then the USB full speed. The scenario of this hands-on we've got our board that is with the boot loader activated. First, I will dump all the user's register for the three users and let's check the value. Then I will connect the user too. Then I will dump again those and see the difference so we can identify that user2 has been used. Then I will reset and I will toggle my pin p10, which is in fact the takes pin of the user1. And let's see if it has been detected by the nbd boot loader. And if it is the case, I would say we are stuck on this user1. It's what I want to demonstrate right now. So first I will launch this common line just some explanation maybe. We connect through the debugging link. The mode is hotplug that means we don't reset because we want to have our boot loader just started. We will read the user2 register user2 register user3 register. If I just return this again it's quite similar only one difference with any IQ but I would say if I connect now on my user2 because you can see I was able to communicate with the boot loader I disconnect but I don't reset my boot so my boot loader is still in the same state and then I will dump again the register. As you can see now on this you've got some different value here here, here and here. This is a bootrate register you've got a different here queue that's happened you've got the takes register that means the value we want to send and here it was for the prescader. So I would say we can see that communication had happened on user2. This was expected I would say. Now I reset my board I'm going to launch again the command to show you I would say we are in a clean state and I will now toggle the pay attend so I take my wire and plug set it to 1 go back to 0 and now I will dump the registers value as you can see here communication has been started for sure the board rate will not be properly set on such kind of thing but we can see that there is a start of communication just by toggling the pin so if your design when you boot up on your board even in bootloader if this pin toggle for any reason then you will be stuck on this user2 and if I want to communicate with my bootloader with user2 it will fail because my bootloader detects something on user1 and gets stuck on this interface ok so I just demonstrated with user2 because it's the most simple with Nucleo I also plug a usb cable on the pair12 and pair11 pin and then I will plug them to my pc so before I will just dump the register value for the usb so here no connection at all and if I plug now my usb cable it has been detected I would say by windows so if I go just in my cube programmer as you can see here a port usb has been seen for the fuse and if I dump again the register I can see some value which indicates that the connection has been done on the usb of the bootloader so that means I can't connect anymore now with my user2 user2 sorry so even use that one it works but now of course with the dfu and usb it will work so this is just tips to make you understand how you can find which interfaces has been activated in your bootloader if you don't manage to connect to the expected interface maybe an activity on another pin could drive to such kind of situation if you still have difficulties to connect with the bootloader thanks dfu can interface I really recommend you to have a closer look in the n2606 on many boards you need to have an external crystal to manage to connect through those interface so we have seen together how you can ensure you have properly activated the bootloader and to investigate which communication interface has been initialized the system embedded bootloader is very useful as ready to use in the chip but it can be updated so if during the power-up sequence of your board some pin level drive to detect the wrong interface you are somehow stuck so you really need to think about this during your product definition the possible workaround you can jump further application in the bootloader when you are sure only the pin state will allow to activate the expected interface this is described in the IN2606 but not possible on all the chip the other possibility is to implement your own bootloader and you can find some example in the kube firmware packages here is a link on the IN2606 document which is a key one and then all the application which describe the protocol to communicate with the bootloader thanks to different interfaces thanks for your attention