 Hi, and welcome. My name is Rafael Taubinger and I'm from IR Systems. This session, it's about how to fast-track book fixes with IR and web reward bench and the new SDM32H7MCUs. This is a shared session and Fredrik Lekam from ST will join me as a presenter. This session is being recorded and you all are in mute. So please make use of the question panel and we will have the team ready to help to clarify all your questions on the fly. There will be also some extra time at the end for some extra Q&A. So to get started, here comes the agenda for the next 50 minutes. We will start with Fredrik Lekam exploring and explaining the high-performing and security-enabled SDM32H72X3MCUs. I mean, of course, we need to know and learn all the capabilities that are available in this new MCUs. And right after, it comes to my part and I will go over all the available features in the IR and web reward bench to help you to track down all kind of bugs and especially the complex bugs. And to finalize it on my side, I will go to a practical demo so you can see exactly how to use all these capabilities directly on the devices. At the end, as mentioned before, we have the summary and some time for the Q&A. And now I will be giving over the presenter here to Fredrik Lekam. Thank you Rafael for the introduction. So my name is Fredrik Lekam from STI Microelectronics. I'm located in France and I am in charge of these SDM32H7 series from a marketing perspective. So I will be spending roughly 10 minutes to show you a brief overview of the STM32H72XH73X series so that you can really follow up easily on the debug session afterward. So first, I will give you just a few hints about what STI Microelectronics is for the people who don't know us yet. So we are a very large company, a semiconductor company, one of the largest in the world with a 2019 revenue of a little bit less than $10 billion, 46,000 people spread over the world, composed of sales organization, manufacturing plant, and sales and marketing division level where we define the product. We have also our own manufacturing machine and this is noticeable from that point of view. So I will now jump on the product presentation itself. So it will not last more than 10 minutes, I guess. It will give you a brief overview of what the new series of H7 is. And I have a couple of examples of application that you can really target with this series. So the first application is a factory automation product. Say you want to make an HMI application that will also perform some control of a process, you will be able to use this kind of device to run your HMI with the large memory that we have embedded on the chip. So that's a device that comes with up to 1 megabyte of embedded flash and up to 564K byte of RAM. But we have also capability to address my external memory with the OctalSpy interface. You have a large set of communication peripherals on both the chip, including the FD-CAN as well as Ethernet, MAC, and USB, and also analog features like faster 16-bit or 12-bit ADC. The other type of application that you can target with this kind of micro is to make a UI, for example, so how we can see on the screen here. So obviously, you will take benefit of the high performance of the chip. So the device is able to run up to 550 MHz from the embedded memory. We have the TFT LCD controller on both the chip as well as graphic acceleration and multiple high-speed memory interfaces, as I mentioned already. Here is also the occasion to mention the graphic support that comes with on a very small package like a 68-pin QFN package. You can already drive a display with that kind of package, and we have also a larger pin count up to 176-pin package. We are also proposing a software library, a graphical library that is named TouchGFX that is now part of the STM32 product offering. The key pillars of this series, so the STM32-872-38725 as well as the 730 value line family are the following. So the performance is obviously one of the key pillars. We have a 2768 core mark that is officially posted on the EMBC.org. We have this architecture on the product that is interconnecting a large number of peripherals that is able to make data exchange between memories or from memories to the external world. We have also advanced security features on this micro that comes with crypto-ash acceleration. We have also some secure services that are available, and obviously the ecosystem is also a big part of the selling point of this product. Regarding the portfolio, so this STM32-872-373 X family is the one mentioned in the red square that you have on the screen now. It shows that this product series is now complementing the rest of the portfolio. It means that, as you know, we have, for example, some dual core lines on this H7, which is the 745747 series, which is on the top of the slide here. We have also some other variants on the left that could be more dedicated for graphic or consumer type of application. So you see that the 722X or 733X family is complementing this portfolio. And as part of it, we are also, we keep supporting the extended temperature range up to 125 degrees C as a maximum ambient temperature. If we look at the security features that we have on the product, so we have various features embedded on the micro. We have crypto-ash block, hardware block, which is able to run a certain number of protocols like algorithm, I would say, so like the AES, triple desk, but also some hacking like the SHA-256. And we also propose a certified crypto library in case you want to run a different algorithm. Part of the MCU, you will find a random number generator. We provide also the device with a unique ID and also some key provisioning should you want to implement some secure firmware install or secure firmware upgrade on the chip. We have some other features like an anti-temper detection pins, memory protection you need to secure boot is also part of the chip, as well as the protection against reading or writing. And some other features like a secure user area, a PC-ROP feature, and also the JTAG views capability. Last but not least, the octal spy interface that we have on the chip. We have two instances are supporting the on-the-fly decryption from external north flash memories. So regarding the different lines, so on this table, you see the three different lines that we are proposing on the device. I will not go through in details on that. This visual is available on the presentation anyway, and you can access it. The key important point to remind again is about the performance, the 550 megahertz. Again, I want to insist on the fact that we are proposing up to 1 megabyte of embedded flash on the chip. Also, we have different variants. You can still procure a device with only 128 kb of flash or 512 kb of flash if you believe that you don't need the 1 meg. All the devices comes with a 564 kb of RAM, and as I anticipated earlier about the temperature support, we propose a support of extended temperature range with the 140 degrees C junction temperature, which does correspond to 125 degrees C ambient. This is rendered possible by using the SMPS, which is the switch mode power supply, which is available on chip. If you want more details, obviously on the features and so on, you can always look at the training material or the different videos and the material that we have posted on the web on this product series. A block diagram here that gives me the opportunity also to highlight the cache that we have on the chip. We have 32 kb plus 32 kb of instruction plus data cache on the chip that will allow the use of embedded memories, but also external memories, for example. It gives the possibility, for example, to connect to the external world by using the octal spy, so you have two instances of this octal spy on the chip, which means that you can use one octal spy, for example, to connect on an external north flash, but you can also connect to an external octal RAM, for example. Regarding the portfolio, you see that we are offering this product series in a wide range of package and form factor. We start with a very small package, like a 68 pin QFN package, which is proposed on the 72575 part number. We go all the way on the right to the 176 pin package that we offer in two form factors, LQFP package, but also UFBGA package. In between, you have a different variant, so you can always select a device that will correspond to your need in terms of integration, easy to assemble, or testing. You notice also that we offer a 115 pin WLCSP package, which is a very tiny 4mm by 4mm package available as well. Here is a use case to show how we do implement, for example, an HMI. I will not go through in details on that. You can look on that afterwards if you want, but it's really an illustration of how we can connect the device to an external display by just using the interfaces and the that we have for the display itself, but also for the external memories. Regarding the ecosystem, the ecosystem is composed of software tools that we propose that is available from the ST.com website. We have configuration tools, development tools, and so on. Regarding the hardware tools, we are selling two different types of kits. We have one Nucleo 144 kit, which does correspond to the STM32 H723. We have also a discovery kit that you see on the screen, which is also hosting a demo, very nice graphic demo. This kit is leaning on the STM32 H735 device. We have also a bunch of channels in order to make the technical support with the online support tool, as well as the community is now very large on the STM32, as you probably know. We have also some MOOC available also for free. Regarding the back to the development tools, I know that usually it interests quite a lot of people. We have this discovery kit and this Nucleo board. This screen gives you the part number that you can procure from one of our retailers on the market. It's available in production and available at all the distributors. The discovery kit is available for $87 resell, while the Nucleo, which is a simpler kit, is available for less than $30. So this is basically ending the introduction to the product. I hand over to Raphael now for the technical session. Thank you for listening. Thank you, Fredrik. Let's go to the second part of this webinar. And I have to tell you that this part is divided in two. So first, I will cover some theory part and explain a bit what's available on features in the Web at Workbench to track down the complex bugs. And the second part here will be mainly the practical part, where you'll see everything I'm explaining in action, how you can really take advantage of it. So it's well known that some organizations or some development groups maybe spend up to 80% of development time debugging. Of course, this depends a bit on if you are reusing code or the experience, the maturity of the group and so on. But then, of course, it's clear that you should have access. As a developer, you deserve to have professional debugging tools. And I think the most important, as we saw, these high performing and security devices, for example, the H7 2x or H7 3x running up to 550 megahertz, you should still have all capabilities to have full control available. So let's go a bit to the theory. And then, as I said, the second part will cover the demo. So if I start here, the IR at Web at Workbench might be known for some of you. But as we always say, it's the world's most widely used embedded development tool. And it's more than ordinary toolbox. There is way more available for you. So it's a professional development tool. So if I start here, we have the debugging and trace probes. So we have the iJet that's, let's say, the entry debugging probe. You can take advantage of a lot of the debugging capabilities. But we also have the iJet trace that goes a bit beyond. So mainly from getting some instantaneous picture to go to the full instructions are being executed. So debugging is very important. And that's the main purpose of this session. But I also have to mention a bit about the code quality. I mean, that's becoming more and more and more important to be aligned with the best practices, some coding standards, MiserC, CertiC, and so on. That's available. And as we all know, most of the bugs, they only pop up during runtime. So doing some runtime analysis, it's also very important. So you can catch these tricky situations, whatever it's, of course, needed before your product goes to the field. And if you're working with safety critical applications, there is also a certified edition of the tool, especially the build tools. I mean, whatever you're using, you're working with industrial, automotive, railway, or medical, we have certified and frozen version. And more and more, it's also becoming important due to security legislation. And I mean, you spend a lot of effort in creating or differentiating your product. So you definitely want to protect your IP and also be sure from the number of units that are being produced. So that's also part of the solution. I have to also mention that this session about tracking down complex bugs is the first webinar of series that you have as ambition. And if you stay tuned, there will be other webinars coming covering functional safety and also security. And of course, also very important. I mean, the professional tools, of course, can help you, will help you to differentiate. But for us, it's key that you have access to our global technical supporting. So whatever you have any issues, we will assist you. And so you can continue focus on your code. So modern ordinary toolbox, that's available. So that's IR and Babbage award venture. So let's go a bit to the debugger part. So as I said, this is the focus here from this part. I mean, as you can see, this screen represents pretty well an application where you have full control. I mean, you have starting by the information having the stack usage very detailed. I mean, you can also have a timeline window where we can have from a graphical data log to interrupt log and even some power visualization available for you. And on top, if you are using an RTOS, we have the RTOS awareness plugin that gives you an insight on what's going on. I mean, the threads, what's the current status, information and so on. And when you need some additional information on how your application is behaving, I mean, some performance analysis or function profiling, that's of course also available. So that information can be shown to you on top of access to registers. If you have variables that you want to monitor, not only when you stop the debugger, but also while the application is running. So what I have to say is that it's a broad range of debugging probes that are supported. We also support ETM embedded trace macrocell. I will come back to that part a bit later when I explore a bit more about IJet trace. And you can even use macros to do some testing or let's say interact with the device in different ways. And a side of a simulator, if you don't have access to the hardware, for example, but already want to develop a search code, you can do a lot with the simulator already. So if you go a bit in detail here on the timeline, that's a bit better. I mean, you can have a graphical representation of variables that you want to monitor, like even print a scene value, for example. But when we talk about Cortex-M devices, there is core site for debugging available. So it's really intended for debugging because let's say separate from the core. And what it will give you, it will give you a lot of additional information while your application is running. And what you can also do is use ITM events. So you can mainly instrument your code in different ways to print out some information you want to monitor in the timeline without affecting the performance. So this is what you can see here on the ITM events. And it's straightforward. You mainly make a call to this macro. And you can choose some different information, including the program counter information. And finally, the power debugging that will mainly, if you supply the power to the target from the debug probe, then some probes supported like the IR probes, iJet, or iJet RACE, you'll be able to get information on how much power your application is using, depending on what processing power you need, or you can even optimize your application for the power consumption. But I will show that in a practical way during the demo also. Talking a bit about the probe, as I mentioned before, iJet, it's really powerful. I mean, it supports all the SDM32 MCUs. It's, of course, high speed. As I mentioned, if you want to supply the power from the probe to monitor the power consumption, you can have it up to 400 milliamps. And you can have JTAG SWD speeds up to 48 megahertz. Of course, there is no limit on the MCU side. And as I mentioned, on Cortex-M devices, especially we are talking here about Cortex-M7, the SDM32 H7 2X73X, of course, supports the core side. And a very powerful part of it is the SWO. That's the serial wire output. And with iJet, you can come up to 96 megahertz. And finally, break points. Everybody loves unlimited break points. And that's, of course, also available for most of the targets. But it's important to have it, yes. And if you want to go a bit beyond, then go to the really advanced capabilities. I mean, we have iJet trace. Before I explore a bit more about the trace probe, it's very important to let you know that in order to use trace, the ETM trace, and we have a trace macro cell, your device also needs to support it. That's exactly the case with the H7 2X and H7 3X. They also support ETM. And here, you might be wondering if you're running, for example, the H735 at 550 megahertz, if you can still use a trace. Yes, of course, because usually what happens is that the trace block, it's half of the CPU block. And you can also, of course, do some configuration to bring that a bit down if you need it. And from some tests, we did. So you might also, of course, be wondering how you connect to the target, there are different ways. I mean, the physical connection, and the test we did by using the MiP 20 connector. We managed to get really high, good quality signals by using the MiP 20. So the device was running at 400 megahertz and the trace clock was at 100 megahertz from the MiP 20. If you go a bit beyond, then it might be recommended that you populate your board with a miter connector just to be on the safe side and avoid any noise, of course, in this trace capability. Good. And some additional information, of course, streaming trace, it's also available. And finally, the SWO bandwidth, and maybe the SWO frequency with IGET race, it's a bit higher. So it can come up to 200 megahertz. And trace will collect all the instructions that are being executed on the MCU. So I will talk a bit more about trace. And mainly, what I want to tell you is that you can get also the zero wire output trace, the SWO trace that you can get with IGET. And of course, if you want to have food trace, you should use ETM. And it's good to make it clear that when you talk about trace, usually people think or mean ETM and web trace macrosel. But there are these two types, the SWO trace that it's, of course, supported here on the H7 TrueX and 3X. But the main difference is that it will be sampled. So you don't get all the instructions, but it will give you a very good idea on what's happening. And then, of course, with ETM trace, every instruction that is being executed will be recorded and you will get the full information. So just that, depending on the probe you have, you can have more detailed information. But SWO trace already brings you a lot of information. It will give you a good idea which parts of the application have been used and so on. So some extra information. If you do debugging and you don't have access to any kind of trace information, I mean, it mainly will give you, let's say you stop your application and by using a standard web probe or let's say IGET, you'll get that instantaneous picture. And we all know that usually when some bug happens until you are able to break or you end up in some part where you can take control again, it takes some time. So IGET will just give you that instantaneous picture, memory, registers, variables. But if you think about using maybe SWO trace or even ETM trace and maybe trace macro cell, you will have the possibility to go back in time. So there will be probably a few millions of instructions available. And that will give you the capability to actually go back in time and understand exactly what was going on before you ended in that tricky situation. So trace, it's really important to make you more effective and to get access to some advanced capabilities. So maybe going a bit into more detail here on the embedded trace macro cell. As I said before, you'll get all the instructions that are being executed. You get information about function trace, the very detailed function profile. As I said, it's not sampled. It's 100% of the instructions. If you have streaming trace, it will stay and collect as long as you run the application, all the information and display it for you. And also, of course, code coverage will be more accurate and more detailed information. So that's what you get on top. But some of these capabilities, of course, you can already get with iJet, but always using SWO. And it will be then sampled, as I said. So what can IRM-based workbench and iJet trace or any iJet probe do for you? Of course, I covered a bit about what capabilities are available. But then the big question that comes is how do you correlate it with the practical use cases? And on top of what I just showed, you also have some powerful features available. I mean, when we come to breakpoints, it's not just standard breakpoints that are available. We have conditional breakpoints where you can have some flag or some variable as a condition. You can have data breakpoints when, for example, some specific areas or variables are maybe being corrupted. And you want to know when there is a read or write access to that area. So I mean, when it comes to pointer problems, illegal instructions or data boards, some misaligned writes, code overrides, so maybe some writes to flash, or peripheral registers, or if the stack is corrupted out of bounds. So by using, of course, these capabilities that I just showed in the slides also mentioned, it will, of course, be way easier to find what you call this million dollar bucks. And what you have to imagine, of course, is that let's say that you have some hard fault. If you are using a print F to try to get some information as debugging, it might take a while to get to where you want. And by having full control of the application with these professional debugging capabilities, of course, it will be way easier. So as I already mentioned, Stack Overflows, if you use a timeline, you can even investigate some, for example, some timing issues in communication protocols, or some general timing problems. And again, the profile analyzer and code coverage will give you very good insight if your application that's behaving, it's not behaving as expected. I mean, it's not that it's directly some buggy source code, it's just that the application maybe needs some different configuration or from even priorities in threads, for example. So the profile analyzer can give you all that insight. So where are you spending your time? What can you do to improve that? And when you, for example, need to certify your application, it might be also important to know exactly which parts of the source code are being used, or are you doing the full code coverage? So that is, of course, very important. So moving on, let's go to the practical part. So let me switch here to the environment workbench. So you can get a better idea. Before I start here, I want to mention that I'm using here this discovery kit. So it's the SDM32H735GDK. And I'm using this free artist thread creation example application here that I, of course, added some additional capability on top. But there are some really interesting projects that you can try out of the box, all compatible with IR. You just generate a project for the environment workbench for ARM. And you just run it. So this is the kit I'm using here. And the example project, I use it here as reference. So switching back here to the IR embedded workbench. So first of all, I want to show you that, of course, we support the full line here of the H7 3N H7 2X devices here. If I go to the list, you can see here what we have. So the full line is here supported. Of course, there are other devices here from ST. But the focus here is on the H7 2X and H7 3X. And as you might know, and I always tell that to customers, by just selecting the device, you have 50% of the configuration for your project. I mean, compiler will, of course, know what kind of instructions can be generated, what capabilities are available. And when we go to debugging, the tool will know what's on the other side, of course, from registers, memory, mapping, and so on. So I will not cover other components of the embedded workbench since the focus is debugging. But of course, the IR compiler, it's well known. And Fredrik mentioned the benchmarks and the core mark. And of course, you get one of the highest values here with the IR compiler. So if we go to the debugger, and if we look here, of course, we support other debug probes, especially the ST link that it's available in most of the ST boards. So you can use a ST link for debugging too. I will focus here on iJet, and mainly because we have some advanced capabilities here, and I want to show that. What you can also see here, or what you should know about is that you can have some different settings. Of course, we start with the driver for the iJet family. But when you connect to the target, we use a flash loader for programming the memory, and that's straightforward. But if you have an application and also a bootloader, there might be some really powerful capabilities for you, because you could just add the image from the bootloader to your application here, and then you can debug from the startup, going over the bootloader, going into the application, if that boot sequence is going right. If the bootloader is already there on the target, no problem. You just load the debug information, but you can still go through step by step. So that's, of course, available. You can include some extra images if you have your application divided in many, let's say, images. And finally, multi-core. Of course, you have a device with multi-core that's also supported here, no problem at all. And we will explore it a bit further, since I'm using an application that it's free ARTUS-based. I selected here the ARTUS-Overnus plugin, and we will make use of it. Good. To finalize here the settings, I also need to let you know that you have the possibility to select different interfaces. I mean, JTAG SWD for Cortex-M. Probably you will go for SWD, because it requires less pins, but at the same time, JTAG pins and SWD pins are common. So whatever, if you use one or other and the pins are available, that will of course work for you. But then very important on the configuration side, I mean, as I said during the slides, if you want to use the SWD capabilities, like serial wire output to collect trace information, you need to select that. If you would have ETM and beverage trace macro cell, you could select that. There are some devices that have actually on-chip the ATB and beverage trace buffer, but I'm not covering that now. But if the device would have that, we could of course use it. And then finally, when it comes to the SWD protocol, I'm running this application, of course, on 550 megahertz, because I want to show you that even if you run this high performance devices, you don't have to give up any of the capabilities that are available. So the protocol, you need to decide either you can use the UART mode, but then you need to set the CPU drop correctly. But if you use the Manchester encoding here, the debugger will detect that automatically. So you don't have to worry if you keep changing the clock and so on. So it will detect it. And the auto mode would just make sure that it can detect that UART is being used or either Manchester. So that's the simple configuration. So once that is all set, of course, I'm able here to connect to the target. And from here, I want to show you the capabilities that you can use. Once I connect to the target, we will get access here to the debugging capabilities. And the first thing is, of course, if you go under the view menu, you will see what usually most of the tools have available from memory or register watch window. But here on IR, you have, of course, also the memory, but not only when you stop the debugger also during runtime. And if you use printf statements and so on, you can use the terminal IO from it. But this is more like the standard capabilities. If you go to the advanced capabilities, we can look here on the SWO trace. We will have the Thailand line that it's already open here, function profiler, different breakpoints that are being used. So if I look on this application, as I said, it's based on the simple thread creation. It has a few threads here. And mainly to make it a bit more interesting, what's happening here is that here there is a DAC wave being generated that gets as input to the ADC. So we have here another test that will mainly do a sampling every five milliseconds to get that information place. Some thread to just handle the buttons here. And finally, the default thread just doing some LED controls. But this is just for information for you. So if I leave this running for a while here, you will see that it becomes a bit more interesting for us. So we can see that I'm plotting here this trace average values here in a graphical way. So you can monitor in a graphical way what's happening with specific variables, for example. Even sine waves can be used here. Of course, it will depend on the values. But then we go here to the interrupt log. And here things become really interesting. And if I just work with the zoom, that's always a matter of zooming it correctly. We have some different interrupts happening here. And mainly what happens is that the sys tick is of course being used for providing the timing for the free artist. The timer two is mainly only used on the beginning before of entering to the artist. And then it stops here. And then we have the pen SV to process some actions here on the core, sorry, on the kernel. And the ADC mainly processes actually it's triggered once there is some ADC interrupt completion, of course. So if I run this a bit further, then I can even show you, let me go back a bit in zoom here. And if this runs a bit more, and I just press the button here, so you can see that now the external interrupt, it's also being triggered. That's all of course very straightforward. But what you can do if we look here a bit deeper again, the sys tick is of course generated periodically, you can do some measurement here. And what mainly happens here, if you go from one interrupt to other, you will see that it should be roughly one millisecond if I'm not wrong here. And it's roughly it should be 1000 megahertz, maybe I started a bit after the line of the interrupt. But you can also see how much time you are spending in time inside the interrupt. So if I just zoom this a bit more, you can see that ADC it's taking 3.56 microseconds. And the pen SV, it's 1.9 microseconds. And when you're configuring the system and everything, of course, this is very handy when you have different priorities and the interrupts, if it's anything affecting your application. And then finally, if I look here on the power debugging, if you want to make sure that the application is using, let's say, not too much power, you can have that information also here, we do sampling of that information. Of course, that is all configured here on the settings. And mainly as you can see, since this application is running at 550 megahertz, we are doing roughly 5,594 samples per second. We could, of course, change that or make it even higher. If you want, it will depend a bit on the bandwidth that you have available. Of course, if you enable all the capabilities, you might come to a limit or might lose some packages. So that's the way it works here. And then finally, as I mentioned, you can do some instrumentation in your application. And what I have here, it's the ITM. And mainly what you need to do, if I just go through part of application here, we have this capability to add some macros here, ITM event. This is, of course, part of the core site. And if I go here to the definition, you can have it with different sizes here, 86 and 32 bit, or even including the program counter and so on. So that's a very straight forward way to keep printing out some information that you want to monitor. In this case, we are using it to show the switch of the tasks of the switch of context here. So that's the way we are making use of the ITM. But you can use it anywhere. And this is like a macro. If you go for your release build, that will not be used. It's only for the debugging mode. And of course, there is way more available here. I mean, as I mentioned, we have the capability to do some function profiling. We also have the option to do some code coverage. So if I just enable the capability here, and I maybe can just rerun this application, maybe we should just clear everything so it starts from scratch here. And once I run the application, you will see that on the code coverage, it just ran for a while here, we press the button a few times. And we will be able to see what's going on. I mean, of course, since it's sampled and I'm using here the IJet capabilities, you have to run it for a long time until you get samples from all the routines. But it already gives you some good idea. If we look here on the function profiler for the performance analysis here, we can see that we spent most of the time here in this scale on the score wave. So if we have some routines that you want to optimize for speed, maybe that's where we should get started, of course. So it gives you a good insight on what's going on. But when it comes to some other features that you should be aware, we have the SWO trace. And I need to bring this window back here because I maybe it's not the best spot to put this window, sorry, got to a different area here. We should just get to reach here. But mainly what happens if I, for example, just start this application again and leave it running for a few seconds. I have here the sampled trace coming out. And if I just go over here the application, we will see that I can put it here actually. So I can just go back in time here and you will see that. So now I'm back here and fully. That's why developers always need two monitors to get everything under control here. But as you can see, you can just keep following here the SWO trace and you can see what's exactly going on here. Finally, what I also want to show you when you want to monitor variables on the fly or maybe even memory. I mean, if I just leave this application running for a while here, we will see actually that it's updating the value here on the fly. So you can see that all the information is being displayed. And the values are being updated here on the fly. So you don't need to stop the debugger to get that information. And the same is of course valid here when you use the memory window. So I'm going here to open the memory window and maybe I should just let it go here. It should already be available here. So it's running here. Sorry, I think it enabled the live update. Now it's enabled here. So as you can see, even the updates in memory are being displayed here in red. So you can have that information on the fly. Definitely, with this full control on what's happening in our application, as I mentioned in the beginning, 80% of time being spent on doing debugging, you deserve access to the professional tools to be more effective. So this is what I tried to show on the capabilities. I could spend, of course, way more time showing you everything we have from the conditional breakpoint to the data log breakpoints or the data breakpoints when there is access to a specific variable. I can maybe just find and show this one. If you look here on this code, there was access to this variable and then the application, of course. So this is a practical part I wanted to explore and show you as a summary. If I go back here to my slides, of course, again, working with high performance devices, STM32, H723 and sorry, H72X and H73X are very powerful, running at 550 megahertz. You shouldn't lose any capabilities and that's definitely the case by using SWO ATM trace profiling. You can identify hotspots, streaming trace, if you have the pins available. You will definitely find the million dollar bugs by using the right debugging tools. Good. Now it's time that we switch to the Q&A. We still have a few minutes left here and I can see that we got some good questions and our team has been busy. That's, of course, very good. We have some questions. If I start here, if this also applies to STM32H4 and 5X. So mainly what I can say and how it was answered, of course, apply for the full STM32 line. The main focus was here to show that even this high performing device, that's still all available in the capabilities. So if I continue here on the questions, I will scroll down to see if we have some open questions. So I'm going over here what we have. Please feel free to still send in questions if there is anything that pops up now for you. So we had some questions on how the IR embedded workbench compares to the STM32 ID. I mean, I tried to best show the capabilities here. But of course, the compiler for faster and more compact code is also a big differentiator from call marks. That's, of course, how we differentiate here on the ID. We had a question about the Touch GFX, if it's recommended for graphics UI development. And yes, we had an answer about that then. It's, of course, part of the examples available for, especially this board that I used here. But there are, of course, other capabilities or other stacks also available. And ST, of course, offers some free of charge. Okay, then we had also a good question about if there are any voice recognition libraries available. And the answer is yes. So it's available and ported over the whole range of high performance STM32 devices. Of course, there are some questions about how iJet compares with J-Link from Sega, for example. And the main side of what was already answered is, of course, it's fully integrated with the ID. We make sure that we can take the best out of the integration. So as mentioned, if you have further questions on that or need more information or some comparison on performance and so on, we can of course provide it to you. Just please reach out to fa.usir.com so we can provide you more information on that. And then we have a very good question. So how much of the capabilities that were explored applied to the nuclear eval board? And this all is definitely doable on the nuclear board. I mean, you have the SWD SWO pins available. So as soon as you connect the pins to the debug rope, all that is definitely available. Yeah. And a very good question. If the IR and beverage workbench provide the code coverage, and I see some comments, what's available. And that's a good point. The call graph, it's a very powerful capability. In this demo, I was not able to show that because the Discovery Kit for the 735 doesn't have the ETM traces pins available. It has ETM in build, but the pins are not available. So I couldn't use it on this probe. But definitely, if you have your own prototype, you will be able to use that fully. And you get this in a graphical way. I mean, top of the code coverage seeing exactly which functions are being called and what's happening in the application. Very good question. So yes. So the question is if the demo was performed only using a single SWO pin. Yes, that it's correct. Only a SWO pin. And SWO was running at 100 megahertz here, actually. So that's what I have. And then we have a final question here about how to set up trace triggers. We have different opportunities, of course, to work with trace with having start and stop conditions or break points. We can do many settings around it, starting by using the ETM from the device that can be used from one to four pins. So you don't need to use the four. You can maybe just use one and then it's compressed, maybe a bit lower, lower speed, I mean, but that's definitely available. So we can catch up offline with some more information about it. And I'm afraid we are running out of time here. But thank you so much for your time. And for all the very good questions. And if you have any additional questions, please make sure to reach out to us. We are happy to help you further.