 Hello, and welcome to this video app note on dual-core debugging with the STM32-H7 microcontrollers using our STM32-Cube IDE. I'm Emily Raderman, and I'm a field applications engineer at ST in the microcontroller division. Let's get started. First, let's begin with the agenda. I'll introduce the basics of dual-core and how it can be useful in microcontroller applications. Next, I'll review the main features of our dual-core system, as well as the debug mechanics that make it all possible. Then I'll explain the specific requirements for debugging STM32-H7 dual-core microcontrollers and the specific debugger settings needed for STM32-Cube IDE. Finally, we'll conclude the video, give you some resources, and you'll have all the tools necessary to start your own dual-core project. The first question we must ask is, why should you use a dual-core system compared to the traditional single-core microcontroller that we all know and love? Well, with twice the cores, you'll see increased processing power. You can do twice the amount of computing per clock cycle because you have two MCUs that will be processing instructions. This also translates to improved performance without increasing clock speed. On a single-core system, to achieve the same level of performance, you'd have to double your frequency. Another important benefit to a dual-core architecture is security. With two cores, a smart architecture design can separate the cores into trusted and untrusted zones for secure firmware updates, secure boot, and any other secure transactions that need to take place. This heterogeneous computing refers to a system with more than one kind of core, which have numerous applications. In order to truly harness the benefits of a dual-core system, you'll need to answer your own questions regarding firmware architecture. How will the two cores balance the workload? Will they be completely separate or will they be sharing information? These design questions will help you select either a symmetric, asymmetric, or bound processing architecture, or something entirely unique. It's up to you to know what each core's responsibility is in your application. To develop a project with dual-cores, you'll need to know how to debug them. Debugging with two cores isn't twice as difficult as debugging with one core, however, there are a few tips and tricks. Specifically, the products in the STM32H7 family that have two cores are the STM32H7X7 and the STM32H7X5. And these are the microcontrollers we'll be focusing on. What makes up a dual-core architecture? No surprise, it's a hardware architecture that has two processors in some memory space, typically with at least one shared region. This is a general diagram of the dual-core microcontrollers' main features. As you can see, there's an ARM Cortex-M7 processor that can run up to 480 MHz and an ARM Cortex-M4 with speeds up to 240 MHz. There are embedded memories, including two megabytes of flash and one megabyte of RAM, both with ECC. There are numerous security features, including secure boot and firmware install, tamper and crypto-CPN. There are graphic modules, as well as typical peripherals like an ADC, timers, and multiple methods for connectivity. You can use a switched mode power supply or interface with SD-RAM, NOR, or NAND memory with our flexible memory controller. There are a lot more, and the possibilities are endless. As I mentioned on the last slide, the STM32H7X5 and H7X7 devices use a heterogeneous core architecture with the Cortex-M7 and the Cortex-M4 processors. You can configure the boot process to your needs, whether both cores start simultaneously or separately, putting one of the cores in charge of waking up the other. Setting up this distinction is easily done in the option bytes. There are four important access ports in this device. You can see two access to the CM7 and CM4 respectively. These ports allow access to the debug and trace features integrated into each processor core. Access port 1 allows access to the bus matrix in the D3 domain, giving visibility to the shared D3 memory and peripherals when the D1 or D2 domains are switched off. The system access port allows access to the debug and trace features on the system APB debug bus, which is essentially all components not included in one of the processor cores. This bus matrix describes the connections between the processors as well as the different power domains, D1, D2, and D3 that separate them. You can see the Cortex-M7 over here, the Cortex-M4 over here, and the AHB bus that connects them, as well as the different memories that are close by. There is the D3 domain to each processor, and you can see it largely contains shared memory space. Now, let's dive into more detail about how these access ports tie into the overall debug mechanics. First, here's some of what our debug infrastructure can do. Both cores can be simultaneously and independently debugged, using equipment connected to the JTAG or serial wire debug port. This allows for breakpoint and watchpoint setting, code stepping, memory access, and so on. Also, when one core stops due to a breakpoint or debugger stop command, the other core can be stopped as well. The cores can be restarted at the same time, allowing for debugging of loosely coupled applications which require the processors to remain synchronized. Tracing information from both cores is combined into a single trace stream and output to a real-time trace port analyzer. There's an ID embedded in the trace to identify the source of the information packet. Lastly, the circular trace buffer information can be stored on chip, dumped off-trip to the trace port analyzer, or it can be read by the debugger, either processor core, or uploaded to a host machine using one of the MCU's many communication interfaces. Here's a block diagram of the debug infrastructure. You can see the debug access port, connecting the JTAG or serial wire ports to the AHB and APB buses that connect to the Cortex-M4, Cortex-M7, the system bus matrix, and other traces and debug subsystems. You can see here that both processors have their own internal debug infrastructure, and there's similar system debug mechanics in place that I'll be reviewing in detail in the next slide. This is how debugging with two cores on STM32Q by DE will look like. You can see the access ports AP0 and AP3 connect to the M7 and M4 cores respectively through the debug access port, which connects to the hardware debug probe connected to your computer running STM32Q by DE with windows for each processor. One of the cool features of ARM cores is the cross-trigger matrix and interface. These two systems allow events from various sources to trigger debug and trace any activity. This is what allows you to set a breakpoint in one core that stops the other processor. There are three components to the cross-trigger interface, one at system level and one for each core. These are connected by the cross-trigger matrix. The system level and the CM4 interfaces are accessible to the debugger via system access port and APB debug bus, while the CM7 interface is physically integrated into the core and accessible via its access port and the AHB debug bus. Each CTI has up to eight trigger inputs and eight trigger outputs. Any input can be connected to any output on the same or different interface via the CTM. The trace port interface unit and the embedded trace macro cell generate the trace packets that allow execution information to be traced. This information includes the number of instructions executed in the same cycle, changes in program flow, the current processor instruction state, exception information, addresses of memory locations accessed, and more. The TPIU or the trace port interface unit formats the trace stream and outputs it onto the external trace port signals. Now let's talk about the requirements for getting your application ready to debug. Dual-core debugging allows simultaneous debugging of both cores using a single hardware debug probe, and that's where the ST-Link GDB server comes in. ST-Link server is an application to share the debug interface of a single ST-Link board among several host applications, like our debugging tool or a monitoring tool. The host application must have the ability to connect to the ST-Link server instead of connecting directly to the ST-Link USB interface. Other ST-Link interfaces, like a virtual comport or the mass storage, aren't managed through the ST-Link server, but can be used simultaneously. This figure shows how the GDB client connects to the ST-Link GDB server via TCP socket interface in order to debug the ARM Cortex-M target connected to the ST-Link JTAG, or serial wire debug. We'll be debugging on the STM32 board, and for the most part, STM32Q IDE takes care of the connections for us. For perfect harmony in debugging, make sure to have both ST-Link GDB server and STM32Q programmer installed on your machine. The ST-Link GDB server will allow us to dive into dual-core debugging, but before we can begin, we need to talk IDE. How can we see each core at the same time when debugging? We're used to connecting to a single core with a single IDE GUI. It's possible to debug simultaneously with both cores, like I mentioned in previous slides, but how it works in practice depends on your IDE. With STM32Q IDE, you can have a single IDE GUI with each core accessible, but using IAR's eWarm IDE, you'll need to use two separate IDE GUI instances. To ensure dual debug, a debugger must have the following attributes, access port selection capability, visibility of all cores, simultaneous multiple core connection capability using the same debug probe, support cross-trigger ARM components, and the possibility to switch between access ports during the same debug session to visualize the memory and the peripheral statutes in other domains. The IDEs in here are all capable of dual-core debugging with the STM32H7X5 and X7. Today, we'll be focusing on the STM32Q IDE. Let's go over the specific IDE settings you'll need. We'll begin with setting up the GDB server, then each core's debug and startup settings. In general, each core will need certain specifications regardless of IDE, the memory region where the code will live, its access port, the STLink and GDB server configuration, and the option to utilize the cross-trigger interface during our debug session. To start configuring the launch of the debug session, right-click the sub-project for the CM7 and select Debug as STM32 Cortex-M-C-C++ application. Move to the Debugger tab and make sure the debug probe is STLink GDB server, and we'll keep the Autostart local GDB server connection. We're connecting with the SWD interface with access port zero for the Cortex-M7. For reset behavior, we'll connect on the reset with halt all cores checked. The cross-trigger interface is optional and in this picture it is unchecked. Lastly, make sure that enabled shared STLink is checked. Now, let's move to the startup tab. On the startup tab, we'll click Add and select the other sub-project, the cm4.elf file. Keep all boxes checked in the add slash edit item window. As a small note, if you want to download and load symbols in different memory regions, here is where you'd specify. This is setting up the Cortex-M7 debug startup to build, download and load both the CM4 and CM7 binaries. Make sure the CM7 is listed lower than the CM4.elf file, because we want the order of operations to end with the CM7.elf file. Now, let's move on to the CM4.debug configuration. On the CM4.debugger tab, we'll again use the Autostart local GDB server setting, the STLink GDB server as the debug probe, but make sure that the port number in the corner of the GDB connection is at least three higher than the CM7. Here I have it set to 61238, which will work fine. We can see the interface is the same, serial wire debug, and then the access port will be three for the Cortex-M4. The reset behavior will be set to none, as we'll be connecting and resetting with the CM7 debug configuration. Lastly, we'll check the enabled shared STLink box as well. Last up, the CM4 startup tab. It's pretty simple here. We'll first click Edit and disable the download, as this will be performed by the CM7 debug configuration. Now, you're ready to debug with two cores! Well, this is fun, and I hope you learned about dual-core usages in debugging with the STM32H7 and STM32Q by DE. Here are some additional resources that dive into more specifics, including the reference manual for the dual-core H7 microcontrollers and a couple application notes that highlight the debugging settings and features I've gone over today. You can find these resources on st.com and in the description below. Thank you for your time, and I hope you have a fantastic day. Happy debugging!