 Today, we will show in this video how to debug M4 firmware with Linux running on A7. Debug is done with SM32Cube IDE on SM32MP1 product. In SM32Cube IDE, we will compile the XTI GPIO project example from the SM32Cube MP1 package, and we will show how to debug the M4 firmware while Linux is running. We will illustrate how Linux loads into the MCU RAM, the M4 firmware, and starts its execution. We are going to open and build the project to get the M4 health binary. See in this wiki page the tree organization of this SM32MP1 package. It provides the IPR drivers and a multitude of MP1 firmware examples. As we have just seen in the debug configuration, there is two way of debugging. The engineering mode is for the development phase of the M4 firmware without Linux. Debug in so-called production mode allows the M4 debugging while the firmware is interacting with Linux. In engineering mode, the bootpins are set to engineering mode. In this case, the ROM code is not started. The M4 is loaded and started through the GTIG problem. In production mode, the bootpins are set so that the loader will start Linux. When we click on the debug icon in CUBE IDE, the M4 firmware is loaded in the Linux file system via an SSH connection. Then Linux loads it in the MCU RAM and starts its execution. Ultimately, the SM32 CUBE IDE, GDB will attach to the SM32 debug port on a running M4 firmware. In this lab, we will use this configuration. The firmware GPIO-STI will toggle an arranged LED on or off via GPIO, upon a DK2 user button press via an XTI interrupt. Before starting this M4 firmware, we have to start Linux with M4 example device tree. This kernel configuration reserves exclusively for M4, an XTI interrupt, and a GPIO. This configuration prevents Linux from using or stopping the clock of these two IP in stop mode. We check at the bottom right status we get in the CUBE IDE that the virtual component setting connection is green. We open the UART console by clicking on the butterfly icon. In this console, we write reboot to reboot Linux and select number 3 in the UBOOT menu to select the right device tree. Let's initiate the debug session. Once we check production mode is selected in the debug configuration. Here we use Ethernet over USB using a cable plugged on the DK2 OTG USB port. We check in the CUBE IDE at the bottom right status we get that the IP address is green. It means that the SSH connection between the PC and the board is functional. Click on the debug icon to start the debug session. Click on the pause icon, it will attach GDB and observe M4 is halted in the main function in the core while loop. You can check if you press the user 1 button that the orange LED does not switch on. Click in pause icon, the M4 firmware execution resumes. If you press on the user button, the orange LED shall be switched on. The loader script CUBE IDE uses the firmware Cortex M4 loader script to load and start or stop the M4 firmware. The script copies the firmware elf into the remote proc loader directory. Then the script sets the name of the elf in the remote proc linux loader. Then it launches the elf loading and execution. Let's see how it works. We will stop the debug session, we will open a console on the target and check the current status of the execution of the firmware, observe the trace showing at the stop or start and the resource reserved for M4. Double check when the firmware is running or not using the user 1 button. We have reached the end of this demonstration, please find some tips. In particular, note the lab 2 which provide more explanation about the resource sharing between M4 and linux. Thanks for your attention. We wish you a good experience with the STM32 CUBE IDE and our STM32 MP1 project.